3 ms·
Go essentially went with the node solution (node_modules). Go's pm will essentially just ensure the version that resides in vendor/, and will work more like yar
by Skinney 10y ago
Go essentially went with the node solution (node_modules). Go's pm will essentially just ensure the version that resides in vendor/, and will work more like yarn than npm. This is, of course, not unique to node.
Having a global vendor folder where everything is the same version regardless of the project seems like a fragile solution to me, especially if you work on a lot of projects. And how would that work with third party libraries? Those would still have to vendor?
I think it's a good thing that Go standardizes vendoring.
- cyphar 10y ago> Having a global vendor folder where everything is the same version regardless of the project seems like a fragile solution to me That's not what I said. The way that every Go project used to do this (which was how Godep solved the problem) is that you have a vendor/src directory in the project. It's very similar to having vendor/ in your project, but the issues I mention are because of the lack of the "src" prefix. If it sounds like a trivial difference, that's because it is (but because of Go's lovely filesystem dependencies it makes everything awful). > I think it's a good thing that Go standardizes vendoring. Sure. I don't think it's a good thing that they standardised an incompatible solution, apparently ignoring how everyone else in the Go community had solved the problem before them.