Quoting Nicolas Mailhot (2019-03-12 04:22:45)
> In a parallel thread, a Nix developer was asking about basically
the
> same use case, and was pointed at `go build -mod=vendor`. It seems like
> this does exactly what is wanted here -- just use the code we have
> locally. Nicolas, does that address your use case?
That's definitely *not* what we want (our processes call for removing
vendor and its equivalents in other languages before going to the
build step).
Not sure we're on the same page re: what was suggested. The idea is
you'd point the vendor directory at something that contains the distro's
versions of the dependencies, and use -mod=vendor to bypass all of the
smarts around fetching modules and such. I was not proposing using an
existing vendor directory provided by upstream or anything like that.
This is more or less what Jakub described in a sibling comment, as far
as I can tell.
As I already noted, there is a deep lack of understanding Go
upstream
side of how we work (for all computer system languages, not just for
Go). What they imagine is not what we need or want.
This definitely jives with my own memories from the last time I was a
maintainer on a distro -- language package managers and module systems
generally tend to be much more oriented towards developers using the
modules than to distro maintainers packaging them. It's to the point
where as an end-user of a distro I have a boat load of executables in
places like ~/.local/bin, because I use enough oddball tools that aren't
popular enough to be maintained by the distros themselves, and packaging
them myself just isn't worth the trouble. I do wish these tools played
more nicely together.