proposal: cmd/go: maintain 'classic' vendor behaviour #44519
Proposal: Maintain 'classic' vendor behaviour
This is a proposal to keep resolution of 'vendored' code consistent with the behaviour possible in
The express of intent to remove
To be clear, this proposal does not make an argument to keep
In order to take any subsequent security updates and language features, teams are faced with non-insignificant engineering and logistical tasks to make this possible. For us and I imagine many others this is multiplied across a number of applications into the hundreds.
Our specific set up is to use git submodules of packages into the
The applications have grown and adapted these structures over time based on the features available in the compiler until now, and the fact that until recently there was no 1st party solution for package management.
Removing the ability to resolve code in this way feels inconsistent with the spirit of the below paragraph taken from the go1compat document, which I appreciate people are likely familiar with.
In the above example,
The text was updated successfully, but these errors were encountered:
To continue using your git submodule layout while using modules, I think you can add a
Unfortunately, "classic" vendor lets you end up with multiple copies of different (or even identical) minor versions of a package in the same build, which causes all manner of headaches. Adding that to module mode would introduce a special case that violates one of module mode's basic guarantees.
I apologize for the work you'll need to do to deduplicate your vendor directories into a single top-level vendor directory. All I can say is that if you make each one use a go.mod instead of vendor, that will set you up much better for understanding which code versions you are actually using, for updating in response to security fixes, and so on. It really does lead to a better, more agile setup.
I would push back a little on the "until recently" part. Go modules were first made available for use in Go 1.11 (August 2018), and we announced our intent to remove GOPATH in the "Go Modules in 2019" blog post (December 2018). Also, Go 1.16 will be supported until the release of Go 1.18 (~February 2022).
Note also that the document explicitly excludes tools such as the Go command. It is concerned with the Go language and the standard library.
We do try to follow the spirit of the document generally, and again we are aware that it is painful to update old code trees. We don't intend to make a break like this again any time soon, if ever. But this one really is necessary for the progress of the Go ecosystem.
@rsc You statement assumes that people always uses other dependencies or such dependences always have version problems. But these simply are not always true. When those cases don't occur, it is unnecesary to enforce all Go code must be in a module. For this reason, the classical behavior should be maintained.