xscDev

Something Something Development

[Release] lein-ancient 0.4.3: Automatically upgrade Project Dependencies and Plugins

with 4 comments

I just released version 0.4.3 of lein-ancient, a plugin that checks your projects for outdated dependencies and plugins. This release includes two useful new modes:

  • :upgrade, which takes your “project.clj” and tries to replace outdated versions with current ones, and
  • :upgrade-global, which does the same for your global user profile in “~/.lein/profiles.clj”.

Both offer options to tweak their behaviour, most prominently :interactive (which let’s you choose which artifacts to update) and :print (which writes the result to the console instead of back to disc). Let’s see how it’s supposed to work:

$ cd panoptic                         # an older project
$ git diff                            # no changes so far
$ lein ancient                        # standard functionality
[com.taoensso/timbre "2.4.1"] is available but we use "2.1.2"
[potemkin "0.3.1"] is available but we use "0.3.0"
[pandect "0.3.0"] is available but we use "0.2.3"

# okay, let's get down to (interactive) business
$ lein ancient :upgrade :interactive
[com.taoensso/timbre "2.4.1"] is available but we use "2.1.2"
Do you want to upgrade? [yes/no] yes
Upgrade to [com.taoensso/timbre "2.4.1"] from "2.1.2"

[potemkin "0.3.1"] is available but we use "0.3.0"
Do you want to upgrade? [yes/no] no

[pandect "0.3.0"] is available but we use "0.2.3"
Do you want to upgrade? [yes/no] yes
Upgrade to [pandect "0.3.0"] from "0.2.3"

# something should have changed
$ git diff
diff --git a/project.clj b/project.clj
index 18a408a..3031031 100644
--- a/project.clj
+++ b/project.clj
@@ -4,9 +4,9 @@
   :license {:name "Eclipse Public License"
             :url "http://www.eclipse.org/legal/epl-v10.html"}
   :dependencies [[org.clojure/clojure "1.5.1"]
-                 [com.taoensso/timbre "2.1.2"]
+                 [com.taoensso/timbre "2.4.1"]
                  [potemkin "0.3.0"]
-                 [pandect "0.2.3"]]
+                 [pandect "0.3.0"]]
   :repositories  {"sonatype-oss-public" "https://oss.sonatype.org/content/groups/public/"}
   :exclusions [org.clojure/clojure]
   :profiles {:test {:dependencies [[midje "1.5.1"]]

Voilà, all the desired dependencies have been upgraded while the rest (and especially the formatting of your project file) has been left untouched. Similarly, :upgrade-global will only alter what’s necessary in your global user profile, e.g.:

$ lein ancient :upgrade-global :allow-snapshots
Upgrade to [lein-marginalia "0.8.0-SNAPSHOT"] from "0.7.1"
Upgrade to [lein-pprint "1.1.2-SNAPSHOT"] from "1.1.1"

$ cat ~/.lein/profiles.clj 
{ :user { :plugins [[lein-marginalia "0.8.0-SNAPSHOT"]
                    [lein-pprint "1.1.2-SNAPSHOT"] 
                    [lein-ancient "0.4.3"]
                    [lein-try "0.3.0"]] } }

See here for installation instructions. Because once it is installed you might never have to manually upgrade your global plugins again. :)

Written by Yannick

July 30th, 2013 at 3:26 am

  • Ephaeton

    I’m not sure this is a good idea. Imho, if you could instead of
    updating the global dependencies, create a new profile, e.g. :after or
    :future, containing the updated dependencies, then, lein ancient could
    have all the test cases run with with-profile, and thus warn the user
    about things not working before they switch their main profile’s
    dependencies over. API stability is not yet something that the clojure
    community seems to value highly (not a huge problem really, there’s a
    lot of 0.x libs out there so we all know this and that’s ok), so not
    switching your main view of the universe to something potentially
    incompatible without a safety net doesn’t seem like such a good idea to
    me. The functionality itself is quite appreciated though, saves a lot of
    manual lein searches.

    • S_Mosciatti

      I agree with Ephaeton…

      Actually I didn’t know of your project, and I was looking for something similar, Thanks

    • http://dev.xscheme.de/ Yannick

      You mean the project dependencies, right? (The global user profile is probably mainly used for plugins, at least I cannot think about a scenario where you’d have dependencies in there right now.)

      I agree that blindly updating dependencies (in contrast to plugins) can be harmful. I think your suggestion is a very good one and I’ll try to incorporate it (in some way or another) into the next release.

      • Ephaeton

        Yes, sorry for the ambiguous wording. I meant the project’s “global”
        dependencies, i.e., not hidden away in some project-specific profile. Thanks for listening.