Clojurians Log v2

I have been using a multiple config strategy, I have a default config in the repo which is more a dev config that anything, but I have a function which will load another aero edn file and merge the two together so I can override and extend the base config. My reasoning for this is more for tinkering with the prod database I can load in the prod databases configuration and run queries against the prod database, feels safer doing this as I have to explicitly load the prod config, I do this instead of using a separate sql app as I can reuse my existing sql and create clerk notebooks when I need to do some db heavy data manipulation.

https://github.com/weavejester/meta-merge/pull/12 for anyone interested.

The specific case I'm looking to get covered is the removal of keys from the built-in config as all other current usecases are supported by the current solution.

Example:

(magic-fn
 {:a 1
  :b 2
  :c {:x 1
      :y 2}}
 {:b ^:remove []
  :c {:x ^:remove []}})
;=> {:a 1 :c {:y 2}}

Aero allows you to have all config in one file and read it based on environment, so any config you want excluded from a particular environment in terms of runtime availability just needs to not be marked for that environment. Of course that does mean you will ship config that is unused / surplus to requirement for a given environment, but at least all your config is in the same place and as such is a simpler maintenance / update problem.

(hopefully that made sense)

https://github.com/juxt/aero#profile

^^ That's the bit of the documentation that you are going to want to read.

Cheers Oliver, unfortunately profiles don't help me here, I have a requirement to use multiple files. Looks like Aero isn't what I'm looking for

Why do you have to use multiple files?

Why not use one file and make use of profiles..?

(That was kinda the point I was trying to make anyway)

My base config which contains rarely-changed and environment-independent wiring is packaged into the uberjar. Environment-specific configuration has a different lifecycle (changes more often), lives elsewhere, and is versioned independently. At startup I deep-merge the env-specific one on top of the built-in one.

I want base config to live with the app source and I don't want to re-package the app when, say a port number changes.

OK, I think that this is pretty subjective. I would just use one file and benefit from profiles. Your not wanting to repackage the app when some config changes is a perfectly valid choice, just not one I would make. Nonetheless, you are right, the advantages of Aero are wiped out by the other concerns / requirements that you have. Sorry I was not more help \o/

In rare cases I want to override the base config in a way that some keys are completely removed in the effective config. That's what I had thought aero could perhaps help with but looks like I'm looking for something like meta-merge instead

Thanks for the discussion anyway 🙂

No problem - any time 🙂

@imre We have the same setup as you and use Aero -- we just merge the config ourselves after reading.

Cheers for the input Sean, I suppose you don't merge it using Aero, but use Aero for some of its other features?

(I ended up just implementing removal myself in the deep-merge algo we use btw, inspired by https://github.com/weavejester/meta-merge)

Right, we use Aero to read EDN and deal with #env / #include etc. We don't use profiles at all.

We have a base EDN for each service (in resources -- ends up in the JAR) and then each server has one or more overriding EDN files per service.

Very similar to our usage yeah although we currently don't use env/include and so don't have a need for areo

@imre yah we use meta-merge

it allows for an interesting new level of abstraction, for config data, namely 'overrides'

since the merge happens before #ref is resolved.

if you put juxt clip systems in your config , also adds new flexibility.

meta-merge doesn't support removing keys though, as far as I could tell

i think you're right, that's pretty useful, i wouldn't mind a fork.

I guess that's what you did internally 🙂

you would have to go up a level in the nested map structure, and do a ^:replace i think.

My addition was to an internal function, but I might consider a pr to meta-merge

I'll ask James whether he'd be interested

any idea on the syntax? you can't associated metadata with keys

:key ^:remove {} maybe , I think we should avoid data_readers.clj for this one obviously.

That's what I supported internally

My first idea was to put it on the key but quickly realized thst wont work