On 2013-10-08 12:51, Bruno Medeiros wrote:
From what I understand, for dependency graph locking to work at all,
then each package (as stored in the central package repository) would
have to specify its full dependency graph in the package specification.
So the foo package would have to specify not only the bar dependency,
but also xyz=0.0.1 as a dependency. Isn't that how it would work?
No, now necessarily. Using Bundler it works like this:
* You have your Gemfile, corresponds to package.json in dub
* You run "bundle install"
* When you do that it will create a new file, Gemfile.lock. This file
contains the complete dependency graph of what it just installed.
* Running "bundle install" when Gemfile.lock exist, it will read
Gemfile.lock instead of Gemfile
By the way, the registry (package repository) need to be able to figure
you the complete dependency graph, otherwise it won't be very effective.
It should only require one single HTTP request to the registry to get
the complete list of dependencies of a given package.
If so, I think that might be too constricting, and might introducing
other kinds of problems and limitations. (what if you know xyz=0.0.2 is
safe to use, and want to install foo with that?)
The way I've done that using Bundler is to explicitly specify that as a
direct dependency, in this case of "foo". I don't know if there's a
better way.
Rather, I think dub should adopt Semantic Versioning as part of its
recommended practices for package versioning:
http://semver.org/spec/v2.0.0.html
In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
upper bound on the version is required, to allow breaking changes in xyz.
Semantic versioning helps, but it won't solve the problem. I wouldn't
trust that a library actually follows the semantic versioning scheme.
It's quite easy to accidentally add new API without incrementing the
middle number. Or break the API.
--
/Jacob Carlborg
