This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-10
Channels
- # announcements (3)
- # asami (19)
- # babashka (38)
- # beginners (42)
- # cider (19)
- # clojure (17)
- # clojure-europe (34)
- # clojure-hungary (3)
- # clojure-nl (1)
- # clojure-norway (53)
- # clojure-uk (7)
- # clojuredesign-podcast (34)
- # conjure (2)
- # cursive (7)
- # data-science (13)
- # datalevin (3)
- # datomic (19)
- # dev-tooling (1)
- # events (1)
- # honeysql (2)
- # hyperfiddle (31)
- # integrant (16)
- # juxt (39)
- # missionary (14)
- # nrepl (14)
- # off-topic (57)
- # overtone (22)
- # podcasts-discuss (1)
- # practicalli (32)
- # reitit (12)
- # releases (2)
- # ring (13)
- # ring-swagger (2)
- # sql (85)
- # squint (75)
Just checking here about juxt/aero: I need to merge configuration files at system startup (built-in config + environment-specific one, both edn files) and was under the impression I could use aero for that but checking the readme it doesn't seem like the case, am I reading that right?
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.
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
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
@U08BJGV6E 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
@U08BJGV6E yah we use meta-merge
it allows for an interesting new level of abstraction, for config data, namely 'overrides'
you would have to go up a level in the nested map structure, and do a ^:replace i think.
:key ^:remove {}
maybe , I think we should avoid data_readers.clj for this one obviously.
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.