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

21–30 of 213 posts

Re: Go += Package Versioning

#21

Post by steveklabnik »

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 basically asked it to not think about it at all. Further, it would significantly bloat binaries, as this would mean many more duplicate versions of packages in your project. Basically, idiomatic use of = is only in very specific situations.

We could have required that you always specify some operator, but we also like reasonable defaults. Writing `^` everywhere is just more typing.

The transitive dependency issue isn't any different, really: that's due to said packages also not using =.

Re: Go += Package Versioning

#22

Post by stormbeta »

bbatha wrote: post #4
eximius wrote: post #3

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

These issues all seem to be solved by lockfiles, which are a part of the dep tool. Why ditch them here? It seems like rsc seems to be hinting at an argument for simplicity. But the long history of package managers, and my anecdotal experience confirms, that you're going to need a lock file no matter what. Good versioning practices are not enough, npm versions 1-4 prove that you need locking, and it must be on by defa…

Not only that, but locking allows for what is IMO the best way to handle this through CI:

Always run your builds with maximal version selection in CI (unlocked), and lock the new versions in if it passes all tests, otherwise leave the previous locked versions and flag it for review.

Re: Go += Package Versioning

#23

Post by Animats »

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 through past version pin decisions.

Some version pinning systems let you import multiple versions of the same package into the same build to accommodate dependencies on different version. That bloats executable code and may cause problems with multiple copies of the same data.

On the other side, once package users are using version pinning, it's easier for package maintainers to make changes that aren't backwards compatible. This makes it harder for package users to upgrade to the new package and catch up. Three years after you start version pinning, it's going to be a major effort to clean up the mess.

The Go crowd tries to avoid churn. Their language and libraries don't change too much. That's a good, practical decision. Go should reject version pinning as incompatible with the goals of Go.

Re: Go += Package Versioning

#25

Post by stormbeta »

warent wrote: post #10
Sir_Cmpwn wrote: post #5

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after I figured out some hacks that I could use to avoid it.

I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational. Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high. The…

gofmt, sure. Consistency in style is great.

But GOPATH was a mistake in the same way Go's hitherto lack of versioning was: it deliberately breaks easy isolation between projects / dependency management.

This mindset only works if you control most of the ecosystem (such as with a monorepo), but it's a irritating mess otherwise.

Re: Go += Package Versioning

#26

Post by __david__ »

warent wrote: post #10
Sir_Cmpwn wrote: post #5

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after I figured out some hacks that I could use to avoid it.

I've been programming in Go for a couple of years now and found that this need to use "hacks ... to avoid it" is totally naive and irrational. Agreed, GOPATH is awkward--at first. Because it's different from what most programmers are used to. But once it's adopted it actually makes a lot of sense, and looking back it seems bizarre to ever have such a strong desire to avoid it at all costs--and the costs are high. The…

It's really not irrational to want to organize my projects in a way other than by their (current) git repo URL. It's also not irrational to not want disparate projects to not share the same pool of dependencies (which even go has begrudgingly accepted as evidenced by "dep" and this proposal). Go is alright but I refuse to drink the GOPATH cool aid.

Re: Go += Package Versioning

#30

Post by condescendence »

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…

Technical debt is definitely something to worry about, however I think most companies' first priority is a working product.

Technical debt is to be handled during the development cycle, not in source code and most of the issues you bring up (bloated software, version pinning) are solved in build systems and again should not be handled by source code.

Anyone working in an enterprise enviorment, especially that has clients on different systems, would instantly crumble without being able to target specfic builds.

Legacy and long term support software is everything.

>Go should reject version pinning as incompatible with the goals of Go.

This would instantly make go a 'no-go' in any enterprise enviorment.

Post reply on HN