Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go += Package Versioning

research.swtch.com

Post reply on HN
Print view View original

181–190 of 213 posts

Re: Go += Package Versioning

#181

Post by notauserhere1 »

notauserhere wrote: post #161
rsc wrote: post #32

Earlier quoted context omitted.

Hi. As I said in that page, I do know that cargo is working as designed, and that "0.4.1" is the same as "^0.4.1". My point is maybe a little more subtle, that cargo takes the newest allowed under the constraints, so given "^0.4.1", it has a choice between 0.4.1, 0.4.2, 0.4.3, 0.4.4, and 0.4.5, and it takes the last. When you're adding a new direct dependency, taking the latest is almost certainly right. But when you…

> I think taking the last is problematic: it seems much safer to me to take the one closest to what the author of that code tested with. If someone doesn't respect semantic versioning the difference of one minor or few minor versions is irrelevant. > For what it's worth, I think I do understand what cargo is doing, and why, and I completely respect that approach. I think understanding SemVer would help a long way.

I get down voted but look at this https://go-review.googlesource.com/c/vgo/+/95700/4/vendor/cm...

hard coding v1 and v2 check, anyone who understands semvar would never make such mistake!

Re: Go += Package Versioning

#182

Post by [deleted] »

rsc wrote: post #32
steveklabnik wrote: post #21

Glad to see this! I'm still digesting the details, but to comment on https://research.swtch.com/cargo-newest.html Cargo does not use the latest version. Saying toml = "0.4.1" is the same as saying toml = "^0.4.1" NOT saying toml = "=0.4.1" which is what rsc would guess. This decision was made because ^ is the most reasonable default; over-use of `=` destroy's Cargo's ability to help you upgrade, given that you basica…

Hi. As I said in that page, I do know that cargo is working as designed, and that "0.4.1" is the same as "^0.4.1". My point is maybe a little more subtle, that cargo takes the newest allowed under the constraints, so given "^0.4.1", it has a choice between 0.4.1, 0.4.2, 0.4.3, 0.4.4, and 0.4.5, and it takes the last. When you're adding a new direct dependency, taking the latest is almost certainly right. But when you…

[deleted]

Re: Go += Package Versioning

#184

Post by codedokode »

Animats wrote: post #23

I 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…

> Over time, though, version pinning builds up technical debt. You have software locked to old unmaintained versions of packages.

If you are talking about open source, it is not a problem: anyone can upgrade dependencies and make a pull request. Without version pinning, the project will always be in a "broken" state.

For example, recently I tried to run Firefox 3.5 on linux and it crashed with modern versions of gobject libraries although they are supposed to be backwards-compatible. I wish Debian package manager allowed to install an old version of a library specially for this application.

Re: Go += Package Versioning

#185

Post by codedokode »

sseth wrote: post #167
baq wrote: post #61

Earlier quoted context omitted.

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.

The picture becomes more complicated when you consider a hierarchy of packages, because presumably the packages you depend on would have their own lock files, which represent the versions those packages have been tested with. npm will pick the latest version of the dependencies compatible with the package.json of the packages (package-lock.json, is not published as part of the package). This means that with npm we ma…

PHP package manager, Composer, uses lock files only for applications, not for libraries. The developer makes sure that everything works and then commits the lock file.

Re: Go += Package Versioning

#186

Post by codedokode »

rsc wrote: post #34
Animats wrote: post #23

I 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…

We do reject version pinning. There is no way to pin a particular version. The only constraint you can express is ">= this specific version". If nothing else pushes it forward, though, you'll keep getting that specific version. But it's not pinning, it's just stating a minimum, and the system uses the single oldest version that satisfies all the stated minimums (the max of the mins).

It is difficult to live without versions pinning in commercial projects. Imagine if you get an urgent task that needs to be completed today, but then you find out that the dependencies were updated, your project doesn't build anymore and you need to fix that first.

Re: Go += Package Versioning

#187

Post by kybernetikos »

munificent wrote: post #33

I'm going to comment mostly on the parts of the proposal that I think are wrong, but don't take this to be an overall negative response. I'm excited to see smart folks working on this, and package management is a really hard problem. There are no silver bullets to code reuse. Context for those who don't know: I along with Natalie Weizenbaum wrote pub[1], the package manager used for Dart. > Instead of concluding from…

> Dart does not let you have two versions of the same package in your application, even different major versions. This restriction does cause real pain

Dart is primarily targetting web deployment, in which code/executable size is a major concern. For Dart's use-case it makes perfect sense to force the developer to sort this out ahead of time, painful as it might be. For lots of other languages (including go), the primary expected deployment is to a binary executable where bloating it with multiple versions of dependencies to make the builds easier and make it possible to use two dependencies with mismatched dependenices of their own is very rarely a problem.

Re: Go += Package Versioning

#188

Post by imtringued »

abvdasker wrote: post #83
baq wrote: post #61

Earlier quoted context omitted.

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.

In my experience NPM shows exactly how to build a package manager. They are slowly fixing the problems one by one but half a decade ago NPM was terrible compared to what it is today.

Re: Go += Package Versioning

#189

Post by wtetzner »

makapuf wrote: post #134
wtetzner wrote: post #91

Earlier quoted context omitted.

If you have a lock file, there's no problem. I was arguing about what happens when there isn't a lock file. I may have inferred something that wasn't in the original comment, by reading too many of the other comments on this page.

Sort but given that we're relying on git mostly, what are the advantages of lock files over submodules/subtrees ?

Well, that would lock all of the projects into git. What if some libraries are in git, and others are in mercurial and darcs?

I think it’s better to have a package manager that’s not reliant on a particular source control system.

Re: Go += Package Versioning

#190

Post by fiatjaf »

Groxx wrote: post #163
Sir_Cmpwn wrote: post #16

Earlier quoted context omitted.

Though GOPATH avoids duplication, it's entirely possible to avoid duplication without GOPATH.

And downloading the full Git repository for every `go get` is frequently a far greater waste than even storing copies of all the versions you're currently using in all projects you work on. GOPATH is unambiguously terrible.

you're right.
Post reply on HN