Go += Package Versioning • Hacker News Board

Re: Go += Package Versioning

#61

Post by baq » Tue, Feb 20, 2018, 7:44 PM UTC

stickfigure wrote: post #58

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…

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.

Re: Go += Package Versioning

#62

Post by kodablah » Tue, Feb 20, 2018, 7:45 PM UTC

stickfigure wrote: post #58

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…

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…

> The Maven approach is unquestionably superior; code always builds every time.

If that's your goal. There's a middle ground which includes security updates: asking the community to follow semver. Rust devs seem to do it well and my crates build well with non-exact version numbers after not visiting them for a while. Not sure why the majority of Rust devs do a good job with this and JS devs don't. I suppose it's the strictness of the contract in the first place.

With Go, I've found popular library maintainers doing a good job at BC contract compat even when there has been only one blessed version. I don't assume giving them a bit more flexibility is going to hurt anything.

Re: Go += Package Versioning

#63

Post by zbentley » Tue, Feb 20, 2018, 7:46 PM UTC

coldtea wrote: post #60

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…

> 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. And as usual Golang ignores progress in the area by package managers such as npm, cargo, et al for what seems like a half-hearted solution. Issues I see: the introduction of modules on…

That's unconstructive and substance-less.

Could you expand on the progress you mentioned, or explain what parts of the counterexamples you gave the Golang folks should learn from? In what ways is the proposal a half-hearted solution?

Re: Go += Package Versioning

#64

Post by zbentley » Tue, Feb 20, 2018, 7:48 PM UTC

dragonwriter wrote: post #48

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. Version pinning does not. Misusing it might, but don't do that. Version pinning of dependencies is a tool for assuring the behavior of releases, but in development you should be generally be updating to the latest stable version of dependencies and then pinning them for the next release, not keeping the old pinned versions.

> Misuisng it might, but don't do that.

Isn't technical debt usually just the situation of having many things that should be done, but aren't? In other words, the accumulation of "don't do that" cases in code.

Re: Go += Package Versioning

#65

Post by [deleted] » Tue, Feb 20, 2018, 7:52 PM UTC

[deleted]

Re: Go += Package Versioning

#66

Post by baq » Tue, Feb 20, 2018, 7:56 PM UTC

this sentence

> First, the meaning of “newest allowed version” can change due to external events, namely new versions being published.

is the root of what's wrong with this proposal - namely conflating time of dependency resolution with the time of build. cargo (using it because it's been referenced by the post) solves this problem by telling you to check in the cargo.lock that it generates whenever you 'cargo update'. this means that your version control preserves the build dependencies, just as it preserves build recipes (e.g. build.rs or travis or whatever). in this world, there's no 'newest allowed version', because there is only one version.

wise men before me said 'as simple as possible, but no simpler' and I'm afraid this proposal is too simple.

Re: Go += Package Versioning

#67

Post by dragonwriter » Tue, Feb 20, 2018, 7:58 PM UTC

zbentley wrote: post #64

dragonwriter wrote: post #48

Earlier quoted context omitted.

> Over time, though, version pinning builds up technical debt. Version pinning does not. Misusing it might, but don't do that. Version pinning of dependencies is a tool for assuring the behavior of releases, but in development you should be generally be updating to the latest stable version of dependencies and then pinning them for the next release, not keeping the old pinned versions.

> Misuisng it might, but don't do that. Isn't technical debt usually just the situation of having many things that should be done, but aren't? In other words, the accumulation of "don't do that" cases in code.

> Isn't technical debt usually just the situation of having many things that should be done, but aren't?

Sure, the things that you shouldn't do are the things that lead to technical debt. What I'm saying is that "version pinning to assure consistent behavior in stable releases" is not one of those things.

What is one of those things is "leaving pins from the last release in place in development".

Version pinning in releases is a means of providing stability for downstream users. It should be encouraged.

Leaving those pins in place while developing the next version is a source of technical debt. It should be discouraged.

Re: Go += Package Versioning

#68

Post by bpicolo » Tue, Feb 20, 2018, 7:59 PM UTC

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

That seems like it only works well if library authors are both extremely well behaved and also don't make mistakes, and there's no way that will be universally true. Every time I've had to pin a version it's because a backwards incompatibility issue or more likely just a bug is, intentionally or not, added to a library.

It's going to be much more painful if people have to fork when a bug is introduced lest they have to wait a week or more to get a bugfix upstreamed.

Re: Go += Package Versioning

#69

Post by steveklabnik » Tue, Feb 20, 2018, 7:59 PM UTC

coldtea wrote: post #60

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…

> 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. And as usual Golang ignores progress in the area by package managers such as npm, cargo, et al for what seems like a half-hearted solution. Issues I see: the introduction of modules on…

Having had lengthy conversations with Sam Boyer on this topic, I know that at least he deeply knows how these systems work. So it hasn't felt like "ignored" to me, at least, as an outside observer.

Re: Go += Package Versioning

#70

Post by Strom » Tue, Feb 20, 2018, 8:01 PM UTC

stickfigure wrote: post #58

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…

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…

> People break library interfaces, that's just a fact of life.

Sure, but in my experience it happens at least 10x as frequently in NPM than with Go. It's really common for me to update all my Go dependencies and everything just continues to work. With NPM I have to start looking for migration documentation and change a bunch of my code.