Is the "import compatibility rule" (ie, `/v2` suffixes in package paths) implemented in vgo today?
Go += Package Versioning
81–90 of 213 posts
Re: Go += Package Versioning
#82I have misgivings about all this version pinning. At first, it seems to make things easier. Programs don't break because some imported package changed. So it looks like a win. At first. Over time, though, version pinning builds up technical debt. You have software locked to old unmaintained versions of packages. If you later try to bring some package up to date, it can break the fragile lace of dependencies locked in…
Just because you don't need reproducible builds doesn't mean nobody needs them.
As soon as some tool is used to provide reproducible builds, you have effective version pinning.
If your organization values avoiding technical debt accumulation over reproducable builds, they don't don't have to use version pinning and can always run 'go get' with the '-u' flag.
> once package users are using version pinning, it's easier for package maintainers to make changes that aren't backwards compatible.
I don't think ease of making backwards incompatible changes with vgo. Both before and after vgo, backwards incompatible changes must go in a new major version / new import path. The ability to pin major versions already exists.
Re: Go += Package Versioning
#83Earlier quoted context omitted.
This is horrible advice. I work in a lot of languages (including Go), which gives me some perspective. On the extreme ends of this issue we have Maven, which specifies hard version numbers (fuzzing is possible but culturally taboo) and NPM, which only recently acquired the ability to lock version numbers and still has a strong culture of "always grab latest". The Maven approach is unquestionably superior; code always…
Lock files are best of both worlds: you specify the latest at check in time and then freeze whatever was picked. No need to reinvent the world.
Yeah it's crazy that there's still so much controversy around this topic considering Node and Ruby have had amazing dependency management for over half a decade at this point. Dependency management in those languages is pretty much a solved problem and the fact that go isn't there yet drives me nuts since I have to work with it every day for my job.
Re: Go += Package Versioning
#84Earlier quoted context omitted.
> When you consider the evaluation of a dependency graph in the context of a SAT solver, you realize that the solver would consider both a minimal and maximal version as potentially satisfying the general constraints found in a dependency graph. Whether you then optimize the solution for a minimal or maximal version becomes a matter of policy, not correctness. I believe rsc is hoping they can avoid the need for a SAT…
Actually, I think the SAT solver is avoided by making the only version constraints of the form Using the min version appears to eschew the need for lock files. Want to upgrade? Bump your min version.
> Using the min version appears to eschew the need for lock files.
This only works if the system also prevents you from publishing a version of a package with a lower number than any previously-published version of that package.
So, for example, after you've shipped foo 1.3.0, if a critical security issue is found in foo 1.2.0, you can't ship foo 1.2.1. Instead, all of your users have to deal with revving all the way up to foo 1.3.1 where you're allow to publish a fix.
It's not clear to me why they're trying so hard to avoid lockfiles. Lockfiles are great.
Re: Go += Package Versioning
#85> Minimal Version Selection Means no security fixes at the price of, well, minor developer inconvenience? What is the inconvenience, exactly? > ...tomorrow the same sequence of commands you ran today would produce a different result. I mean, I guess this is technically true. But seems like it shouldn't be an issue in practice as the API you're calling shouldn't have changed, just the implementation. If it has changed…
> I mean, I guess this is technically true. But seems like it shouldn't be an issue in practice as the API you're calling shouldn't have changed, just the implementation. If it has changed, then downgrade the dependency? And if the new implementation has a new bug, you might be screwed. It worked last week, but not this week. How do I get back to the working version?
Use 'git bisect' or some similar tool to walk back and find the point where the lock file change triggered the bug?
Re: Go += Package Versioning
#86Please don't remove vendoring...
Yeah, this.
You want reproducible builds? Vendor your crap. Check it into your repository. Live free.
Re: Go += Package Versioning
#87If there is neither GOPATH nor vendor directories, where will the downloaded packages be?
I digged vgo a bit and found the downloaded packages currently reside in `$GOPATH/src/v/cache`, and seems like vgo won't work without GOPATH for now (https://github.com/golang/vgo/blob/b6ca6ae975e2b066c002388a8...).
Re: Go += Package Versioning
#88Will there be an official proxy or will open-source projects still break when someone moves/deletes a repository?
That's what local caches are for.
Re: Go += Package Versioning
#89Earlier quoted context omitted.
> There's a middle ground which includes security updates: asking the community to follow semver. No, that doesn't work. People make mistakes, and you end up not being able to build software. It might work _most_ of the time, but when things break, it's of course always at the worst possible time. I think Cargo got it right: use semver, but also have lock files, so you can build with _exactly_ the same dependencies l…
Sorry for the confusion, but that's what I meant. I was addressing the use-exact-versions-all-the-time argument. Maven goes too far in that it is taboo to do anything but use specific versions. Cargo, composer, etc do follow the proper approach. Maven w/ version numbers like "[1.2,1.3)" shouldn't be so taboo IMO. The "commit lock files for apps and don't for libs" is also practical.
Ah, OK, we're in agreement then :)
Re: Go += Package Versioning
#90Amazing that in 2018, a language team needs to be convinced that versioning packages is a good idea.
What's next, persuading them that generics are pretty cool too?