23 ms·

I hate this. Go has been putting off vendoring for such a long time because they "didn't want to come up with a half-baked solution". I think that's bull, and i

I hate this. Go has been putting off vendoring for such a long time because they "didn't want to come up with a half-baked solution". I think that's bull, and it just wasn't a priority for the at the time Google-heavy team since they have a different dependency need (fueled partly by the NIH-syndrome). Now, they release this half-baked solution which has no true advantages over the existing vendoring tools other than keeping our import path the same in your source file (which just makes things more confusing imho). No solution for dealing with dependency conflicts, not even tools to detect and manage them other than the compiler itself. On top of that there's even more "magic keywords" that you need to learn which causes stuff not to behave as you expect, just like the magic comments. I understand it is also a consequence of having a v1.0 and a backwards-compatibility guarantee, but nearly all features added after 1.0 seem to be added with as minimal effort as needed to get something working, which is not a good thing. It all feels tacked on, the easy way, and not thought out.

aleksi 11y ago
My initial thought as an author of "traditional" package manager http://gonuts.io http://gonuts.io was like your. But then I understand that there is no dependency conflicts. Libraries A and B vendor library C, maybe even different versions C1 and C2 of it. Then your project uses A and B and knows nothing about C. As along as libraries don't do anything stupid like modifying http.DefaultClient, everything is fine.
ngrilly 11y ago
I disagree. The experimental vendoring mechanism introduced in Go 1.5 is simple but powerful. In fact, it's very similar to what Node.js does with the nested node_modules directories. The Go team has provided the fundamental mechanism. Now, the community can provide the tooling to manage the packages and the related metadata (like npm in Node.js or pip in Python, but hopefully without the warts…).
justthistime_ 11y ago
Looks like they are trying to exhaust all possible bad ideas, before picking the solution that works. I expect that they don't even know what works yet, because NIH and "it didn't exist in the 1970ies".
- vanessa98 11y ago
  Go packaging is a black hole of sadness in light of all the experience and research that's gone on in this space.

aleksi 11y ago

My initial thought as an author of "traditional" package manager http://gonuts.io http://gonuts.io was like your. But then I understand that there is no dependency conflicts. Libraries A and B vendor library C, maybe even different versions C1 and C2 of it. Then your project uses A and B and knows nothing about C. As along as libraries don't do anything stupid like modifying http.DefaultClient, everything is fine.

ngrilly 11y ago

I disagree. The experimental vendoring mechanism introduced in Go 1.5 is simple but powerful. In fact, it's very similar to what Node.js does with the nested node_modules directories. The Go team has provided the fundamental mechanism. Now, the community can provide the tooling to manage the packages and the related metadata (like npm in Node.js or pip in Python, but hopefully without the warts…).

justthistime_ 11y ago

Looks like they are trying to exhaust all possible bad ideas, before picking the solution that works. I expect that they don't even know what works yet, because NIH and "it didn't exist in the 1970ies".

vanessa98 11y ago
Go packaging is a black hole of sadness in light of all the experience and research that's gone on in this space.