undefined | Better HN

0 pointspeterevans8y ago0 comments

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.

0 comments

dilap8y ago

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...")

cesarb8y ago

> 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.

infogulch8y ago

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.

j / k navigate · click thread line to collapse