Feature #10065: Make `gem env` command output valid YAML

• Status: Feedback
• Priority: Normal
• Assignee: drbrain (Eric Hodel)
• Target version: -

[david_macmahon (David MacMahon)]

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?

[drbrain (Eric Hodel)]

• 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.

[david_macmahon (David MacMahon)]

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...

[david_macmahon (David MacMahon)]

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).

[drbrain (Eric Hodel)]

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.

[david_macmahon (David MacMahon)]

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.