Skip to content
Fetching contributors…
Cannot retrieve contributors at this time
153 lines (120 sloc) 5.86 KB

Leiningen Plugins

Leiningen tasks are simply functions named $TASK in a leiningen.$TASK namespace. So writing a Leiningen plugin is pretty straightforward; as long as it's available on the classpath, Leiningen will be able to use it:

(ns leiningen.debug
  (:require [clojure.pprint :as pprint]))

(defn debug
  "Emit a pretty-printed representation of the project map."
  (pprint/pprint project))

Plugins may be installed on a per-project or user-wide basis. To use a plugin in a single project, add it to your project.clj :dev-dependencies and run "lein deps". To install it for your user, run "lein plugin install ARTIFACT-ID VERSION".

Writing a Plugin

Start by generating a new project with "lein new myplugin", and add a leiningen.myplugin namespace with a myplugin function. Add :eval-in-leiningen true to your project.clj so Leiningen knows to execute its code inside the Leiningen process rather than spinning up a subprocess.

Some tasks may only be run in the context of a project. For tasks like this, name the first argument project. Leiningen will inspect the argument list and pass in the current project if needed. The project is a map which is based on the project.clj file, but it also has :name, :group, :version, and :root keys added in. If you want it to take parameters from the command-line invocation, you can make the function take more arguments.

Tasks without a project argument will be able to be run from anywhere.

The "lein help" task will display the first line of the task function's docstring as a summary. Then "lein help $TASK" will use the task function's full docstring for detailed help. The function's arglists will also be shown, so pick argument names that are clear and descriptive. If you set :help-arglists in the function's metadata, it will be used instead for those cases where alternate arities exist that aren't intended to be exposed to the user.

If your task returns an integer, it will be used as the exit code for the process.


If your plugins need to do a fair amount of filesystem-y things, you may want to take a look at using Ant tasks to do them since the JDK lacks a lot of simple functionality of this kind. Using the Ant API directly is a pain, but it can be eased to a degree using Lancet. Lancet is the Clojure adapter for Ant that is developed as the sample project in the Programming Clojure book.

You can look over the Ant API documentation's listing of tasks to find an appropriate task. See the deps task for an example of how to call a task from Clojure.


You can modify the behaviour of built-in tasks to a degree using hooks. Hook functionality is provided by the Robert Hooke library. This is an implied dependency; as long as Leiningen 1.2 or higher is used it will be available.

Inspired by clojure.test's fixtures functionality, hooks are functions which wrap tasks and may alter their behaviour by using binding, altering the return value, only running the function conditionally, etc. The add-hook function takes a var of the task it's meant to apply to and a function to perform the wrapping:

(ns leiningen.hooks.integration
  (:require [robert.hooke]

(defn add-test-var-println [f & args]
  `(binding [~'clojure.test/assert-expr
             (fn [msg# form#]
               (println "Asserting" form#)
               ((.getRawRoot #'clojure.test/assert-expr) msg# form#))]
     ~(apply f args)))

(robert.hooke/add-hook #'leiningen.test/form-for-testing-namespaces

Hooks compose, so be aware that your hook may be running inside another hook. To take advantage of your hooks functionality, projects must set the :hooks key in project.clj to a seq of namespaces to load that call add-hook. Note that in Leiningen 1.2, hooks get loaded and used without being specified in project.clj; this is a bug. In 1.3 and on they are opt-in only.

See the documentation for Hooke for more details.

Altering Leiningen's Classpath

Leiningen's classpath will include all plugins from :dev-dependencies as well as user plugins. To further modify the classpath of Leiningen itself, add a '.lein-classpath' file a project's root. Its contents will be prepended to Leiningen's classpath when Leiningen is invoked upon that project.

Clojure Version

Note that Leiningen is an implied dependency of all plugins; you don't need to explicitly list it in the project.clj file. You also don't need to list Clojure or Contrib, but you will be locked into using the same version of Clojure that Leiningen is using.

Versions of Leiningen prior to 1.2.0 used Clojure 1.1, while the rest of the 1.x line uses Clojure 1.2. Leiningen 2.0 will use Clojure 1.3. If you need to use a different version of Clojure from within a Leiningen plugin, you can use eval-in-project with a dummy project argument:

(eval-in-project {:local-repo-classpath true
                  :dependencies '[[org.clojure/clojure "1.3.0"]] 
                  :native-path "/tmp" :root "/tmp" :compile-path "/tmp"}
                 '(println "hello from" *clojure-version*))


Custom classpath elements can be added to Leiningen's startup command by adding a '.lein_classpath' file the the working directory. When present, the content from '.lein_.classclasspath' will be prepended to the classpath before invoking the JVM.

Have Fun

Please add your plugins to the list on the wiki.

Hopefully the plugin mechanism is simple and flexible enough to let you bend Leiningen to your will.

Something went wrong with that request. Please try again.