A Proposal for Package Versioning in Go

Re:A Proposal for Package Versioning in Go by elliotlarson on Monday March 26, 2018 @12:57PM (#16680381)

No kidding. I'm so impressed with most of Go, but this is just silly. I feel like Rust started out with solid dependency management in place, at least it's been there from the early days. I work a bit with Node and Ruby too. Both have solid dependency management in place. I mean there are warts, but generally the problem is solved. Actually, now that I think about it, Yahuda Katz has had a hand in working out dependency management for all of those technologies, Rust, Ruby and Node. Maybe the Go guys should bring in Yahuda to help out. If nothing else, he could probably help them get out of the paralysis of analysis loop they seem to be in here.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by sitkack on Monday March 26, 2018 @02:11PM (#16681065)

Rust is good but not great. Being able to import two major versions of a lib into the same compilation unit (am I understanding this correctly?) is a huge win. Rust can have transitive deps that only differ by version number, but they can't come in contact with each other (don't cross the versions).

Reread the post, the authors make some great, mature realizations that I hope other languages will listen to. I don't use the language, but I use languages that Go has affected and this is a great thing.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by the_mitsuhiko on Monday March 26, 2018 @03:28PM (#16681692)

> Rust is good but not great. Being able to import two major versions of a lib into the same compilation unit (am I understanding this correctly?) is a huge win.

The one time I needed that I found a pretty good workaround: you make two crates `helper_old` and `helper_new` and have each depend on different versions of that crate. Then I just pub re-exported the crate it depends on.

That way your other crate can now depend on two different versions of that dependency.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by necubi on Monday March 26, 2018 @07:36PM (#16683744)

This is also the standard approach in the java world, where it's known as "shading."

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by WatchDog on Wednesday March 28, 2018 @03:06AM (#16695992)

"Shading" obviosuly comes from the plugin of the same name. But I think of shading to refer more to the practice of repacking classes into a single jar, than the renaming of package name spaces. As far as the standard approach to supporting muliple library versions in one application, i think OSGI is probably the closest thing to a workable solution.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by sitkack on Monday March 26, 2018 @05:19PM (#16682700)

Genius! I trust you will be authoring a new book "RustOps in Practice".

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by rickycook on Monday March 26, 2018 @05:47PM (#16682938)

seems like that’d be a decent compiler trick

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by msie on Monday March 26, 2018 @02:27PM (#16681222)

> import two major versions of a lib into the same compilation unit

When does this situation come up? What is a compilation unit in this case?

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by hinkley on Monday March 26, 2018 @03:58PM (#16681969)

It comes up with apis that deal with data storage or IPC concerns.

You might need a handler for both versions if you have customers that use the old api and ones that use the new one. Or different departments of the same customer.

Or if you dodge that bullet but have to write a custom migration tool to get data from the old version and cook it to go into the new one. Half of the code is read only and the other write mostly but they still have to coexist if you do anything more complex than a backup/restore script.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by eat_veggies on Monday March 26, 2018 @02:42PM (#16681338)

If the newer version of some library has some breaking changes, you can migrate bit by bit instead of doing it all in one go.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by smaddox on Monday March 26, 2018 @03:10PM (#16681572)

If this is the only motivation for multiple dependency versions in the same compilation unit (crate), I'm not convinced. You would be trading off the simplicity of each crate specifying a range of acceptable dependency versions for specifying `N` ranges of acceptable dependencies, and requiring one of each. Much better to enforce one version per compilation unit, and if you want to get complex with your dependencies, then break your project into multiple compilation units.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by justincormack on Monday March 26, 2018 @11:51PM (#16685078)

That needs language support too, some languages simply do not support it. I believe this includes Go due to how linking works. This could be fixed but it would be hard, maybe a 2.0 thing and it does make package management harder. And in a monorepo it doesnt happen so Google doesnt care.

[ Parent | on HN ]

Re:A Proposal for Package Versioning in Go by bjz_ on Tuesday March 27, 2018 @08:56AM (#16687812)

> I feel like Rust started out with solid dependency management in place, at least it's been there from the early days.

Rust had actually been through three failed package manager projects before they decided to bring in the domain experts at Tilde. Nice that at least that bit of churn has been forgotten - but yeah, it became obvious over that time just how non-trivial the problem is. Cargo makes it seem easy though ;)

[ Parent | on HN ]