[peterevans]

I'm really excited about all this! No more GOPATH, no need for vendor directories; I think this is a positive step forward for Go, and package management in general. I'm also interested in seeing if there's any wider adoption of these ideas in the larger package management ecosphere.

One thing I've been mulling is whether this setup makes more sense in compiled languages than it would with dynamic languages. In the latter, your code base is your executable, so there may not be much difference between this and having a traditional vendor directory.

Of course, using semantic import versioning is something that can stand alone.

[gkya]

GOPATH is one weird thing that I have never been able to justify to myself when trying out Go. I keep all my code under ~/co, I clone others' repos under ~/co/External, many times I clone sth. to /tmp first, and move to ~/co/External if I see fit. Then this language comes around and says "well, that's not how you're supposed to do it, or you'll have to set this variable every time". Just good riddance.

> I'm also interested in seeing if there's any wider adoption of these ideas in the larger package management ecosphere.

If I'm not mistaken, isn't most of this how things work already? The minimal versioning algorithm may be novel, but things like locking dependency versions, no weird preconceptions on where you put code, easily caching dependencies etc. are nothing new in the greater programming community. But whatever, I'm happy that Go's taking this path.

[pokstad]

Vendor directories are the simplest way to include the deps with your project. Removing that ability would complicate many existing projects. Now instead of git, we will need an additional tool to properly vendor our deps .

[peterevans]

I am afraid I don't exactly agree. If you are publishing a library, for one, it's best not to include any vendored dependencies to begin with. But, ideally, no one should include vendored dependencies, whether a library or executable; those are things that can be fetched at build time. ("But, what if the dependencies disappear?" you may ask—this would be handled through the caching proxy in Russ' proposal.)

The additional tool you would need to build your software would be vgo.

[dilap]

For smaller teams/apps, it's super-handy to be able to just include dependencies in the repo. I'm guess this is one of the capabilities vgo will gain in response to community feedback.

(The Go folks have a bit of a blind spot for environments that don't have heavy duty infra. Recall how their initial solution to a montonic clock was "just arrange for your ntp server to not do that...")

[cesarb]

> those are things that can be fetched at build time

At least for Linux distributions, the package builders are normally not allowed any network access; this was an issue for packages using Rust before cargo-vendor and the introduction of a flag to cargo to never try to update the lockfile.

Not allowing network access for build hosts is probably not limited to Linux distributions, so this use case will have to be addressed sooner or later.

[infogulch]

It's a simple system. If the modules are already present in your local cache it will just use them directly. So not having network access for build time is trivial to work around: just put the packages you depend on in your local cache and you're done. Note that with this system the selected versions are deterministic, so if the modules are present there's no reason to access the network anyways.