Adding YAML to the stdlib

[Zachary Gershman]

Hey All,

I wanted to get feedback here first before I move this over to the golang-dev mailing list (or maybe we even just start a change-set).  YAML as a spec is not the greatest and some would even describe it as "gross" but most if not all config files are written in some form of YAML (see kubernetes as a prime example).  YAML was not included in the stdlib and luckily for all of us the awesome go-yaml emerged as the de facto standard for a majority of developers.

Now, inclusion into the stdlib must pass a high bar and not everything can / should be included but I believe that when you have over 1300 packages depending on an outside library, you should at least have the discussion openly about whether it should be moved into the stdlib.

Also, it is slightly unfair to have the expectation that the community should support a significant format through independent OSS work.

[Caleb Spare]

I sincerely hope we never add YAML to the stdlib, as that would
increase the amount of YAML in the world.

> Also, it is slightly unfair to have the expectation that the community should support a significant format through independent OSS work.

Can you explain this? I don't follow.

-Caleb

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Zachary Gershman]

I don't think the "I don't want this format in because I don't want to see more of this format" doesn't work. People are going to keep using it, YAML isn't a format that is going anywhere and I would love to know what you would suggest most people switch to as an alternative (don't say TOML or JSON).

Clarifying my point on the community - I think the expectation that we as the community most continue to have gustavo/others maintain this specific project or fork it when they become tired of maintaining it (which happens) is unfair. If the community likes the way this package is implemented we should have it be officially supported. 

[Jesper Louis Andersen]

On Fri, Sep 23, 2016 at 8:06 PM, Zachary Gershman <zger...@pivotal.io> wrote:

I don't think the "I don't want this format in because I don't want to see more of this format" doesn't work. People are going to keep using it, YAML isn't a format that is going anywhere and I would love to know what you would suggest most people switch to as an alternative (don't say TOML or JSON).

On one hand, adding YAML to the stdlib seems like a simple thing which is easy to do: pick the current solution out there and embed it.

On the other hand, beware! Once added, it undergoes the Go 1.x contract of backwards compatibility, including subtle errors. If a library lives outside the stdlib, it has the ability to evolve in a freer way, on its own release cycle.

My suggestion is to look at the interconnection needed in the stdlib for it to live outside. Are the current tools in place to make it as easy to interact with YAML as it is with JSON? If affirmative, keep hacking! If negative, think about what is missing and/or needed to make the interaction better.

As for the quality of YAML as a format, I've had trouble with it on several occasions. Amazon has had YAML with files embedded in the YAML. Here, indentation plays a crucial role and it creates some subtle hard-to-debug errors quickly. Of course, these problems might have fixes which I don't know of, but the things I saw did not impress me. I also agree JSON is a bad format for configuration--it is far from a succinct format: S-expressions, or Erlang Terms, are usually simpler and shorter than JSON. And both of those formats are not exactly terse by themselves either.

--

J.

[Gustavo Niemeyer]

Hi Zachary,

You have already seen the thread, but for the benefit of others, Zach's email comes from a thread raised and replied to yesterday on Twitter:

https://twitter.com/jvehent/status/778687333956587522

As I said there, the yaml spec is big, messy, and I wouldn't encourage having the package in the distribution of Go. Something being well known and appreciated is not a reason to have it in the standard library.

Also, there's nothing unfair about maintaining go-yaml. This was developed years ago while porting the first projects of Canonical to Go, and is by now widely used there, and we remain committed to supporting it. I also receive regular fixes and contributions from the community, and nobody seems upset to do so.

The most recent change was to replace the LGPL license by Apache, which was well received. I was able to negotiate that based on requested from the community, and were were able to do so due to the CLA that is requested for contributions (ironic that most people CLA's as evil, yet it was used to open permissions further).

--

gustavo @ http://niemeyer.net

[Andy Balholm]

What do you mean by “community”? Is it those of us who aren’t employed by Google?

Is it any more unfair for the Go team at Google to expect Gustavo (or others) to maintain his YAML package than for some in the community to expect the Go team to take it over?

Andy

[Ranjib Dey]

I'll ditto what Jesper said. Go's stdlib is fairly stable and coherent. YAML library does not support encoder/decoder that you can use with arbitrary io.Reader/Writers to marshall/unmarshall stuff.

YAML as a spec if very messy. It allows embedding variables which has been exploited to hack backend apps (rubygems e.g). Buts thats more related to the spec.

I dont see any obvious pain in keeping it outside the stdlib, as long as its maintained (Gustavo doing an aweseom job already)

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Paul Borman]

I would like to point out that Go itself is maintained by The Community.  Sure Google has employees dedicated to Go (we use it internally, of course), but Go has been, since the beginning, and open source project with serious contributions from within and without Google.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Zachary Gershman]

Yes and vibrant open source projects need other outside contributors - that's not the point that is being made. Bringing it into the stdlib guarantees a level of support independent of the community.  That guarantee doesn't depend on anyone one community members or even multiple members but by all of the maintainers of the stdlib.

On Friday, September 23, 2016 at 11:34:06 AM UTC-7, Paul Borman wrote:

I would like to point out that Go itself is maintained by The Community.  Sure Google has employees dedicated to Go (we use it internally, of course), but Go has been, since the beginning, and open source project with serious contributions from within and without Google.

On Fri, Sep 23, 2016 at 11:29 AM, Andy Balholm <andyb...@gmail.com> wrote:

What do you mean by “community”? Is it those of us who aren’t employed by Google?

Is it any more unfair for the Go team at Google to expect Gustavo (or others) to maintain his YAML package than for some in the community to expect the Go team to take it over?

Andy

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Zachary Gershman]

Here's what I would add - lets make these changes and get it stable BEFORE we pull it in. I should be a thing we are happy to see merged. This can all be address in the changeset that proposes the merge. I don't see this as a huge blocker you just have to address this on the front side before it gets merged into the stdlib.

[Zachary Gershman]

Gustavo - it is not jus that YAML is well known, it is also widely used (as I even mentioned). It is a standard even though some may not want to consider it as such. If I can read xml in the stdlib why not yaml? And it is widely supported now but are you committed to supporting it for as long as golang is around?

[Gustavo Niemeyer]

On Fri, Sep 23, 2016 at 5:02 PM, Zachary Gershman <zger...@pivotal.io> wrote:

Gustavo - it is not jus that YAML is well known, it is also widely used (as I even mentioned). It is a standard even though some may not want to consider it as such. If I can read xml in the stdlib why not yaml? And it is widely supported now but are you committed to supporting it for as long as golang is around?

Things don't need to be on the standard library for people to conveniently benefit from them, whether widely used or not.

And I also don't need to commit my life to yaml. :)  The package is Canonical's copyright and nicely licensed, and if we drop the ball someone else can pick it up, as usual in open source. The fact we've been maintaining it for years and it's widely used as you point out probably means we're not doing such a bad job, though.

gustavo @ http://niemeyer.net

[parais...@gmail.com]

Anybody can write a spec and deem it a standard.

YAML is certainly not a common data serialization format. Adding a YAML parser is in my opinion the least of of Go's priorities when one can see all the packages pilling up @ /x/ namespace that should have been in the stdlib already. More tools supporting XML development might actually make more sense, like support for SAX,XML schema,SOAP, XSL,XPath and all these API a lot of entreprise developers still need to interact with. Because frankly working with XML in Go is a pain in the arse.

[Axel Wagner]

a) A package doesn't need to be in the stdlib to have more than one maintainer. If you believe go-yaml needs more maintenance, you can either ask Gustavo to give more people push-access, or create a better-maintained fork. There are tons of go projects out there that are well-maintained by a vibrant community, so, obviously, inclusion in the stdlib is not necessary for a project to get community-maintained.

b) The reason I don't use go-yaml (apart from the fact that I don't like the format particularly) is, tbh, that I dislike the API. I think it's fair, that it should get *much* closer to encoding/json before being considered for the stdlib.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.