lein-simulflow

I suggest to check boot instead.

Combine several long running lein tasks for leaner workflow.

NOTE: Very early version, not usable.
NOTE: Might be over-engineered.

“Daydreaming is the first awakening of what we call simulflow. It is
an essential tool of rational thought. With it you can clear the mind for
better thinking.”

– Frank Herbert, Heretics of Dune

Usage

Check example project.clj.

Put [lein-simulflow "0.1.0-SNAPSHOT"] into the :plugins vector of your project.clj.

For now, install output-to-chan, support and plugin using lein install.

$ lein simulflow

Overview

While doing modern project with both Clojure and ClojureScript your workflow might require running several lein tasks parallel. This means you would have to open several terminals and run tasks like following:

$ lein less auto # or gulp, compass, etc.
$ lein cljx auto
$ lein cljsbuild auto dev # or lein fighweel dev
$ lein midje :autotest

Or you could use lein-pdo:

$ lein cljx once # Because pdo might run cljsbuild before cljx is ready
$ lein pdo cljx once, cljsbuild auto dev, less auto, midje :autotest

Lein-simulflow will start your long running tasks with one command and takes care of task dependencies:

$ lein simulflow

The difference between those is not only the number of commands to start the development env but also number of JVM's they launch. Each lein task will start a JVM to run the lein and many plugins (e.g. cljsbuild, cljs, midje, repl) start another JVM to run code in envinroment of the project. lein trampoline could be used to stop the lein JVM after the project JVM has started.

	Number of JVMs
Plain	7
Trampoline	4
Pdo	4
Simulflow	2, (1 with trampoline)

Note: It could be that running all plugins in one JVM causes problems.

Features

• Works only with custom wrappers:
  • Cljsbuild, cljx, less
• Watch for file changes using Java 7 API (uses inotify or similar OS provided API)
  • Means also that not every plugin has to implement file watching again
• Tasks can depend on other tasks
  • Cljsbuild requires that Cljx has written the cljs sources
• Tasks run in parallel where possible
  • Eg. cljx and less
• Prepend output from tasks with the task name (by capturing *out*)
• Runs all tasks in one project JVM
  • Saves memory in comparison to running e.g. lein cljx and lein cljsbuild seperately

TODO

• Test how well the java.nio.file.WatchService works for OS X
• Filter file events based on regex (or fn)
  • E.g. to filter out Vim temp files

NOTES

• Might be this feature should be built into Leiningen and plugins would implement some API to provide long running tasks.
• If we are already running all tasks on project JVM, we might as well run them from repl...
• Not sure if this best implemented as lein plugin. project.clj is already quite complicated has too much "config magic".
  • I think the situation is similar to Grunt JS Task Runner which many have replaced with Gulp.
    • Gruntfile. Config mostly defined on one big JS map with every plugin having top-level key on config.
    • gulpfile. Tasks are composited from functions returning transform streams. One can use higher-order functions to create parametrized tasks.

Contact

Ping Deraen on Freenode irc.

I would like to hear if you have thoughts about how to solve the problem of many long running lein tasks, about this implementation or if you think that the problem is non-existent.