I was reading this new article about the proposal for package management in Go, and started wondering about a particular aspect that is mentioned: partial code upgrades.
It is of course possible to build systems that use semantic versioning without semantic import versioning, but only by giving up either partial code upgrades or import uniqueness. Cargo allows partial code upgrades by giving up import uniqueness: a given import path can have different meanings in different parts of a large build. Dep ensures import uniqueness by giving up partial code upgrades: all packages involved in a large build must find a single agreed-upon version of a given dependency, raising the possibility that large programs will be unbuildable.
Nimble (and Nim itself for that matter) don't support a dependency on two different versions of the same package. Is this a problem that will bite us in the future?
I'm curious what everyone's thoughts are.
In the JVM world, maven for Java and sbt for Scala have been used to build pretty large projects. Obviously, they run into the multi-version-dependency problem too, and they can handle it without "partial code upgrades" (not the smartest name IMHO). They use shading, which roughly means re-introducing the same dependency under a new name. We can already do something similar with nimble now in a clunky, manual way: clone an old version of a package locally, give it a new name and import using this name where necessary. This is horrible, because the import statements in the source files have to be touched, but it should work.
I don't see dependency hell upon us yet, but the fact that Nim is strong on metaprogramming and tries to keep the language core lean means that a lot of functionality will end up in packages. So nimble maybe should brace itself for trouble, especially if Nims popularity takes off eventually.
Please, focus on Nimble lockfiles. :-)
Nimble (and Nim itself for that matter) don't support a dependency on two different versions of the same package. Is this a problem that will bite us in the future?
No, IMO it's a very reasonable limitation.