Bundler-style version ranges with locking?

[Korny Sietsma]

Hi folks. I'm generally loving Leiningen, but I am finding it a bit
annoying that you end up having to lock all your dependencies to a specific
version - it's a pity it can't work a bit more like ruby's Bundler system.

For those unfamiliar with it, Bundler uses not only a list of project
dependencies (stored in a file called Gemfile) but also a list of the
actual versions of libraries used locally, stored in a file called
Gemfile.lock. The first time you run "bundle install" it works out your
dependencies based on your Gemfile, installs them, and creates a
Gemfile.lock with the current library versions. Thereafter, "bundle
install" uses the versions in your lock file instead of looking on the net,
where possible. You have to run "bundle update" explicitly if you want to
update to the newest valid versions.

This means you can use version ranges far more easily - most of the
problems listed at
https://github.com/technomancy/leiningen/wiki/Repeatability are resolved by
checking in your lock file. This defines which library versions are valid
and tested for a particular revision of your code; CI servers and the like
can know precisely which version to use; but a developer can easily run
"bundle update" and update all the minor changes, bug fixes, etc. that are
out there, and then re-run their test suite to make sure nothing breaks.

I don't know if there is some way to duplicate this with Leiningen. I've
seen a tool to tell you which jars are out of date in your project, but
that isn't really the same, as it doesn't let you say "I depend on version
2.3.* but I don't want version 2.4 or later"

Thoughts? Obvious things I'm missing? :-)

- Korny

[Phil Hagelberg]

Mieczysław Daniel Dyba writes:

> This is a neat idea! Where would we start if we wanted to implement
> this? Does anyone know of existing libraries that would facilitate
> developing this feature?

The first step would be to adapt lein-outdated to only show updates that
you are actually cool with. Probably the best way to do this would be
metadata on individual dependency vectors.

:dependencies [[org.clojure/clojure "1.5.1"]
^:update-bugfixes [clj-http "0.6.5"]
^:update-all [com.mycorp/internal-project "1.8.0"]]

Then you could adapt lein-outdated to pass it on. One way would be to
have it return an updated project map instead of printing it so that it
could be composed with other higher-order tasks such as lein-thrush.
Another way would be to have it just write it out to disk. You'd have to
be careful to preserve comments and the whole project.clj file (since
sometimes there can be arbitrary Clojure forms before or after the
defproject form.

There's some discussion of the topic here:

https://github.com/technomancy/leiningen/issues/1124

-Phil

[Mieczysław Daniel Dyba]

This is a neat idea! Where would we start if we wanted to implement this? Does anyone know of existing libraries that would facilitate developing this feature? 
—
Sent from Mailbox for iPhone

On Thu, Apr 4, 2013 at 7:20 PM, Korny Sietsma <korny-***@public.gmane.org> wrote:

> Hi folks. I'm generally loving Leiningen, but I am finding it a bit
> annoying that you end up having to lock all your dependencies to a specific
> version - it's a pity it can't work a bit more like ruby's Bundler system.
> For those unfamiliar with it, Bundler uses not only a list of project
> dependencies (stored in a file called Gemfile) but also a list of the
> actual versions of libraries used locally, stored in a file called
> Gemfile.lock. The first time you run "bundle install" it works out your
> dependencies based on your Gemfile, installs them, and creates a
> Gemfile.lock with the current library versions. Thereafter, "bundle
> install" uses the versions in your lock file instead of looking on the net,
> where possible. You have to run "bundle update" explicitly if you want to
> update to the newest valid versions.
> This means you can use version ranges far more easily - most of the
> problems listed at
> https://github.com/technomancy/leiningen/wiki/Repeatability are resolved by
> checking in your lock file. This defines which library versions are valid
> and tested for a particular revision of your code; CI servers and the like
> can know precisely which version to use; but a developer can easily run
> "bundle update" and update all the minor changes, bug fixes, etc. that are
> out there, and then re-run their test suite to make sure nothing breaks.
> I don't know if there is some way to duplicate this with Leiningen. I've
> seen a tool to tell you which jars are out of date in your project, but
> that isn't really the same, as it doesn't let you say "I depend on version
> 2.3.* but I don't want version 2.4 or later"
> Thoughts? Obvious things I'm missing? :-)
> - Korny