We don't use Component in production, because it's way too heavy for us. Our web store uses Datomic, PayPal and Stripe, and a few AWS services, and none of these need to be started or stopped.

But we do take a tip or two from stuartsierra's "Reloadable" work flow (which he based Component on), specifically that there should be no global state, and all dependencies should be passed into functions that need them as a parameter.

In our case, we call it `env` since it's the "environment" that a function runs in or can affect, and contains things like the database connection, email service, etc.

Some of these are records which implement a protocol, so that you can have e.g. LiveEmailService in production and MemoryEmailService in development or while running tests.

All in all, I like and have used some of Stuart's ideas, but not necessarily Component itself. There's strong mindshare for it in the Clojure community right now, and it's tempting to look at it as The Solution™ for almost everyone's use-cases because of that. And the ideas it has are good, but that doesn't always mean it's the best solution for each person.

Isn't your use of an env as a parameter just another form of global state?

If not, can you elaborate?

Consider unit testing. With global state, it gets harder to keep things clean; requires more "resetting" type code.

You are right. Params can be references to state, either as an atom or ref, or to a function which accesses external state (e.g. a database). The idea that params somehow obviate the need for state overlooks that.

no, they're just data being passed in. at least thats what it sounds like to me.

obviously this data has ways to manipulate the world, because an app that did nothing would be pointless. but it's no different than any other param.

what would be bad, which is pretty much the opposite of this situation, is if you had global resources that werent passed in as params and caused side affects and you had to access a global variable to get to it (because it wasn't passed in).

Difficult? I have a few lines in a namespace that grabs `git describe --tags` and a few other things and places them in a json file. This is served up internally by all http-speaking applications as `GET /_internal/build-info`.

https://gist.github.com/emidln/8f5993a37ff300e36897debe9c5bf...

Do those lines also name your jars as "project-2.7.11-g03d04c5a.jar" or similar?

No, but only because load-file doesn't play well with all of my dependencies. However, that still doesn't seem like job for a plugin, given that this works out of the box with leniningen:

      :uberjar-name ~(str "foobar-%s-"
                      (-> (clojure.java.shell/sh "git" "rev-parse" "--short" "HEAD") :out .trim)
                      ".uber.jar")