Configuring your noir app

[clojure-newbie]

I was wondering what conventions people are using for configuring their noir applications.

For example, many frameworks follow a convention of using 3 or more config files for different environments, such as testing, development and production, so that you keep database URLs and other settings cleanly separated.

The noir-blog and other examples I've seen use environ settings, which is somewhat suboptional for real-world use, especially as apps get more complex with a large number of possible configurations.

What practices are recommended for noir ?

[Mark Rathwell]

I have a config namespace in my current app. That config has a var
called *mode*, whose value can be :dev, :prod, :stage, etc. Based on
that value, mode-specific config values are used, and elsewhere in the
app mode-specific branches are traversed.

At the moment, I have all configs in the one file, but this can be a
problem if there is sensitive data (such as AWS credentials, etc.)
going into source control. The best solution I have found for this in
other languages is to have a config.template that basically lists all
of the settings that need to be present, but with junk values, and
that will go into source control. Then, configs for each mode
(config.dev, config.prod, etc.) that reside only on your machine (not
in source control) and are pulled in to the appropriate build.

In Clojure, you can do something similar with in-ns. You would have
config.clj, then config_template.clj, config_prod.clj, config_dev.clj,
config_stage.clj which would all be 'in-ns config.clj', and load the
appropriate file from config.clj based on the mode setting. Only
config.clj and config_template.clj would go into version control, the
others would be excluded.

For a lot of people, though, it seems having this information in a
private github repo, for example, is not as much of a concern, so I
don't see it a lot. Some people also just store all of this
information in their project.clj, but I prefer the separation of
runtime configurations from build configurations.

Anyways, my two cents.

- Mark

[Michael Gorsuch]

I have actually be relying on env vars, but I'm deploying my apps to
Heroku so that makes a lot of sense.

Across the board, though, that is the strategy I've used for a large
number of components. Each project of mine has its own directory, and
an .env exists within that houses my development environment
variables. You source that file and then launch. In a Unix-oriented
environment, it really does seem like a natural fit.

Best,

Michael

--
Michael Gorsuch
http://github.com/gorsuch