proposal: cmd/go: partial vendoring #52604
The go mod vendor capability is great for insulating a working program from changes made in imported modules.
It would benefit from having the ability to download only those modules that are imported from external entities.
Within a single entity, every project that uses a popular module and the vendor capability will store a copy of the same code. With multiple projects referencing this popular module, multiple copies will be stored in the owning entities' source code repository.
Modifying the vendoring capability to download only modules owned by external entities would be a useful change. Reuse of the GOPRIVATE env var might make sense, but if overloading the semantics of this variable is problematic a new one could be added or a switch added to the command.
The text was updated successfully, but these errors were encountered:
I think partial vendoring is a fine concept, but I wouldn't want to key it on
However, there is one added wrinkle: the
...but that's probably ok, given lazy module loading! We would at least still be able to load the dependencies from modules whose versions are listed explicitly in the
I'm not fixated on any particular solution, GOPRIVATE was just an off the top of my head suggestion.
My primary goal is to be able to use the vendor capability in an organizational entity (MyOrg) to draw a line between modules "owned" by other entities (IOW: vendors) and those owned by MyOrg.
This, in order to protect the viability of a critical Go program that depends on stuff owned by "someone else" where it is possible that that other stuff may just up and disappear.
The secondary benefit is being able to avoid multiple copies of MyOrg modules in MyOrg's SCRaM system, which should make rolling out critical bug fixes in heavily reused MyOrg modules safer and easier.
Copying code owned by entity B protects entity A from being unable to compile their Go program because entity B deleted their repository.
Copying one's own code into multiple projects does indeed waste disc space, but also makes search, tracking, management and maintenance more complicated.
Programs owned by A that reuse a module also owned by A become more difficult to maintain by requiring a manual step to update the copy of the reused module in each project.
Assume, say, fifty programs owned by A that all reuse module X which is also owned by A. Fifty copies of that module exist in the SCRaM system and there you have your wasted disc space.
Also, to update each program when a bug in module X is fixed is easy if all fifty projects refer to the source repository of module X, more difficult when each project must be manually updated to copy the new module X code into all fifty projects.
Certain kinds of search in that SCRaM system will also return fifty results, not just one, because of the multiple copies.
The ability to distinguish between owned and not owned code when making a "vendor" copy also assists in management of other entity bounded operations, such as license change, tracking and management.