The vgo proposal is accepted. Now what?

Re:The vgo proposal is accepted. Now what? by jchw on Tuesday May 29, 2018 @08:29PM (#17183903)

I think Cargo-like is the direction things are headed even with vgo. In a way, though, I don't think the answer is that Go is "special," just that they wanted to explore the problem space of package management, dependencies, etc. in more detail before locking things down. It may have ended in a slightly weakened ecosystem temporarily, but I hope it helps to ensure that the semantics and behavior of Go's package management is level headed and simple. Hopefully, by Go 2, a lot of the common concerns with the Go programming language will be answered...

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by lobster_johnson on Tuesday May 29, 2018 @09:13PM (#17184187)

The vgo proposal explicitly rejects the "Cargo way" [1]. There's no lock file, and the MVS algorithm requires, as far as I recall, that the go.mod file is modified whenever the developer wants to update to a new version.

[1] https://research.swtch.com/vgo-repro

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by jchw on Wednesday May 30, 2018 @01:01AM (#17185196)

Indeed, but it does seem like a central repository is possibly the direction it's headed, or at least away from source repositories. Personally, I won't be too upset by MVS if it's one of the only deviations, though I do agree with Sam Boyer on the matter, who I actually had the pleasure of speaking with a bit ago.

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by steveklabnik on Wednesday May 30, 2018 @02:29AM (#17185525)

Cargo doesn’t require a central repository at all, to be clear.

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by dikaiosune on Wednesday May 30, 2018 @03:14AM (#17185726)

I'd actually be interested to find out how Cargo's performance compares in a situation as TheDong describes where all of the dependencies are being fetched directly from git.

Part of me wants to say "well of course Rust's tool is faster" but it would be interesting to see just how much crates.io acts as a performance optimization for running builds, installing deps, etc.

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by greysteil on Wednesday May 30, 2018 @05:08AM (#17186209)

Cargo performs dependency resolution, so fetching from git would (and does) significantly slow it down - it wound need to perform git operations to get the tags for each dependency (quick) and then checkout each tag to look for the subdependencies of that package at that version (slow).

Having a central registry is a must for package managers that perform version resolution and want to do so quickly, as it can serve them all the metadata they need to do that resolution.

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by steveklabnik on Wednesday May 30, 2018 @05:55AM (#17186397)

My perception is that the initial clone is slow, but that’s it. A detailed comparison with actual numbers would be interesting!

When you depend on a git dep, you can say if you want a particular branch, tag, rev, whatever. So it’s only a clone + checkout. From there you read the Cargo.toml, same as anything else. That’s my understanding anyway, it’s been a while since I poked at the guts.

[ Parent | on HN ]

Re:The vgo proposal is accepted. Now what? by greysteil on Wednesday May 30, 2018 @07:12AM (#17186697)

You’re totally right - I was thinking of Composer, which does flat resolution for git sources so has to go through the above. Cargo sidesteps that issue completely by taking the head commit or whatever’s asked for :-)

[ Parent | on HN ]