Feature #10065
closedMake `gem env` command output valid YAML
Description
The output of gem environment
is close to being valid YAML, but the GEM CONFIGURATION
section uses key => value
instead of key: value
so the output cannot be parsed by YAML. The attached patch changes just one line to make the output of gem environment
be valid YAML.
I could not find a specification for the output of the gem environment
command so I am filing this as a feature request rather than as a bug.
The attached patch is the minimum change necessary to create valid YAML. I think the structure of the resulting YAML output is not optimal. It is currently a one element Hash whose only value is an Array of one element Hashes. Is it preferable to address that in a separate feature request or as an expansion of this one?
Files
Updated by drbrain (Eric Hodel) almost 11 years ago
- Category set to lib/rubygems
- Status changed from Open to Feedback
- Assignee set to drbrain (Eric Hodel)
Why does it need to be YAML?
I don't think it was ever intended to be YAML and with your change it will be too clumsy to be useful.
Updated by david_macmahon (David MacMahon) almost 11 years ago
It doesn't need to be YAML, but does it need not to be YAML? It is sooooo close already why not make it YAML? Besides, much of the info in the GEM CONFIGURATION
section (where the only non-YAML syntax exists) comes from YAML files already (i.e. ${HOME}/.gemrc
and the system-wide gemrc
file), so why output that in a different format?
How would the proposed change make it too clumsy to be useful? If anything, it makes it less clumsy to use. The current output of gem environment
cannot be eval'd by Ruby, so what benefit does the rocket ship provide over the colon?
Without the proposed patch:
$ ruby -r pp -r yaml -e 'pp YAML.load `gem env`'
/Users/davidm/local/lib/ruby/2.1.0/psych.rb:370:in `parse': (<unknown>): did not find expected '-' indicator while parsing a block collection at line 16 column 6 (Psych::SyntaxError)
from /Users/davidm/local/lib/ruby/2.1.0/psych.rb:370:in `parse_stream'
from /Users/davidm/local/lib/ruby/2.1.0/psych.rb:318:in `parse'
from /Users/davidm/local/lib/ruby/2.1.0/psych.rb:245:in `load'
from -e:1:in `<main>'
Emulating the proposed patch at runtime:
$ ruby -r pp -r yaml -e 'pp YAML.load `gem env`.gsub(" =>",":")'
{"RubyGems Environment"=>
[{"RUBYGEMS VERSION"=>"2.4.1"},
# etc...
Updated by david_macmahon (David MacMahon) almost 11 years ago
I just realized that the current output is actually valid Markdown (at least Github Flavored Markdown). The proposed patch does not change that at all. It just makes the output valid (Github Flavored) Markdown and valid YAML!
The other ideas I allude to at the end of the original post would affect the Markdown aspect of the output, but let's keep those out of the current discussion (for now).
Updated by drbrain (Eric Hodel) almost 11 years ago
I don't understand the value of loading the output of gem env
as YAML when you can query the fields directly from RubyGems itself.
With the exception of subcommands of gem env
such as gem env path
and gem env home
the output of gem commands is not API. I don't want to encourage parsing the output as YAML and I don't want people to clumsily jump through hoops (Hash inside a single-element Array) when real API exists.
Updated by david_macmahon (David MacMahon) almost 11 years ago
Eric Hodel wrote:
I don't understand the value of loading the output of
gem env
as YAML when you can query the fields directly from RubyGems itself.
In "Ruby-only" or "Ruby-dominant" environments I agree that there is little value. It would allow passing the RubyGems config to something (e.g. a diagnostic logger) that doesn't know about the RubyGems API.
In "Ruby-barely-tolerated" environments it is one small way to make RubyGems "play nicely" with the less enlightened.
I don't want to encourage parsing the output as YAML
Not encouraging and actively preventing are two different things. One of the great things about Ruby (IMHO) is that it gives developers lots of freedom to do what they want (even if it's not the "right" way to do things).
If you still feel strongly about actively preventing it from being valid YAML, then please feel free to reject this feature request.