Data, configs & env

Hi everyone!

I’m currently starting to build large-ish stuff with Clojure, and I found myself wondering how I should deal with configuration data (paths, uris, etc) and other variables I might want to define and change.

It seems like EDN is the way to go, but it’s not really clear how I should use it. Let’s say I want to keep some data in an atom:

(def config 
  (atom {:mapper []
         :splits []
         :in-file ""
         :out-file ""
         :id-fields []}))

I need a structure like this because I have to connect to different files and sources, so i can swap! their value when needed. For the moment what I do is to put these atoms in their own namespace, but let’s say I want to change values between production and development and it becomes pretty clear that this is not the greatest idea :sweat_smile:

So the question is if the way to go is really EDN or if there’s something else out there I’m not aware of that might help me.

Not totally sure what you’re trying to accomplish but it seems like you might be mixing up your true configuration with your runtime state a little bit.

In any case, you could either have multiple atoms (dev-config and prod-config for example), or just multiple top level keys (:dev and :prod) in the config map, and then somehow inject the right config based on your current environment.

There are a handful of clojure libraries that might help with this specific “injection”, and possibly an alternative way to think about what you’re trying to accomplish overall.

Check these out:

1 Like

Thanks! I didn’t know about environ, I’ll take a look at it. I tried, but I don’t really like it.

The fact is I’m doing ETL: I’m reading a certain number of very large files coming from different folders (I don’t have control over the files/folder configuration), so I’m using atoms to keep track of what I’m doing at the moment and to move on to the next file when finished.

Basically I have functions that ‘calculate’ and swap! values starting from some fixed variables (that might change between environments and/or during time). So, yes, ETL sucks :sweat:, I have state basically everywhere (I read from a folder, process stuff in memory, dump temp files in another folder, read and process them furtherly and then dump everything to a database) and I was trying to encapsulate it as much as possible while keeping the ability to easily change some values at runtime.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.