A Proposal for Package Versioning in Go

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 ]