Fork me on GitHub

Can I get some criticisms of that code?


I feel like I am over designing freaking config too early


Until you start adding more implementations of Config, config-val can just be a function that takes a Properties argument. merge-configs can just do a regular merge and return a new merged Properties


although personally I would go map first rather than Properties first, unless you have some interop thing that needs it to be Properties


Even then it might make more sense to convert the map to a Properties right before interop, rather than using Properties everywhere


yeah i can probably add an (into {} ..)


only reason I didnt convert it was because i only ever read, I didn't need to work with it


Ill get rid of the protocol for now but keep the config-val function


I think I'll need to load secrets from AWS and some less important values from a config value


but I think you are right



đź‘‹ 4

How do you store and access configuration in your Clojure apps?


I've got such case:


I need some convenient way to store and access information like file-path or other properties which are used by variety of functions in my system.


keeping thing „purely functional” I end up passing dozen of parameters for each function.

Shantanu Kumar14:07:31

I tend to use and to get the effect you mentioned. Sorry about the unintentional plug.


Or creating some one map (like system) with all the configuration stuff.


But then I end up passing this config map to each function… is this the correct way to go?


Or I should not think about it and just pass all necessary arguments to function?


And care about it later, in place where it will be executed (especially that this function is still „low level” and does not necessarily have to know anything specific about how configuration will be stored, etc.


@slawek098 there are really 2 concerns to address here - one is storage and encoding of the configuration; the other is turning that configuration into system components that your code can access


For the second concern, there are 2 approaches - represent the system as a map that gets passed to each function (as you said - this is the approach taken by the Component and Integrant libraries), OR represent it via global Vars (that's the approach taken by the Mount library - I'm personally very much in favour of the first approach for most cases, but there is controversy about that in the Clojure community.


About storage and encoding, the typical approach is to store it as EDN - potentially in conjunction with a lib like Aero


The "evaluation" of that config will depend on the library you use - Integrant offers it's own EDN format, while for Component you may want to use something like Schematic (


You can also roll out your own homemade alternative to Component / Integrant, but it can be tricky to get right once you aim at making it REPL-friendly.


Well, usually I've crafted something like „system workflow reloaded” but simpler just to fulfill my needs.


Maybe I have to dig into Component and Integrant finally…

đź‘Ť 4

@val_waeselynck Do you happen to know a good example application where integrant is being used to orchestrate the system?


I'm no authority on "good", but there's


@val_waeselynck Thank you! This is useful. I'm curious for typical usage patterns of Integrant. We've created a wrapper around Component that does a lot of the hard work like dependency resolution, configuration boilerplate etc. I'm wondering if I'm missing out, but it seems Integrant still requires a lot of manual work regarding dependency resolution. And I also notice that there are many ways in how you can use integrant (both strength and weakness IMO)


> but it seems Integrant still requires a lot of manual work regarding dependency resolution. What do you mean by that? I don't seem to have encountered this problem.


Never liked the idea of having functions to be force-fed a system map or other components. But I do like the core idea of components, to have a single entry point to put the system in the right state. For this reason, if I had to pick a mainstream lib, I'd pick mount over ss.components (for instance). In practice though, I rolled my own and never looked back (if you are curious, it's not a library, it's a convention on top of tools.namespace


controversy in action 🙂 I actually very much like the idea of the "system as an argument", because it reifies the environment of your code into a value, making it more programmable and explicit. I find this useful for testing among other things, and also for operations like "forking" etc.


Yeah, no worries, at the edge of personal taste.


Component vs Mount is the new Vim vs Emacs


You could argue component (or integrant) do not force anything, you're free to add a few fns to make the system accessible globally


the local-vs-global mismatch is gonna hurt though


Oh yes, in theory @mpenet. But people I work with tend to do what the manual and the examples show.


I personally don't like the mount approach. but yeah, vim/emacs etc


We use component at work, but if I had to start over I'd choose integrant.


@mpenet I've been disappointed in Integrant actually - I find it's choice of "inheritance as the mechanism for reuse" very impractical, making the configuration quite hard to read, especially when some type of component appears in several places in the system, or when components are polymorphic.


Ah, interesting


There are a few things I don't like with component as well, first of all it being quite closed to contribs and managed in a rather odd way (pr's a never merged, patches are usually rewriten, even for typos)

âž• 4

And that's also why I prefer to roll my own (and try to convince people to do the same 🙂.) You need <50 LOC to have a fully working component system in your project, and that's completely under your control.


Yeah, then I have the colleague who is not used to it and objects saying "this is not standard". Blah, the best framework is no framework.


I've only used mount so far, but now you got me interested in rolling my own.

đź‘Ť 4

Did some of you work with a composition tool like that wraps component and resolves dependencies? I haven't seen much development in this area


I didn't, sorry.


Not sure if it's what I mean. I see that you have to manually declare dependencies. From the README

:app {:sc/create-fn 'user/map->App
         :sc/refs {:server :webserver}
         :sc/merge [{:to [:api-keys] :from [:api :keys]}]}
I might miss some nuance of course


We have created something that allows to declare component constructors in an edn file and configuration and dependencies will be sorted out based on the components definition. This is really nice in a big system. I haven't seen something like it yet


I think I don't see the difference between "manually declaring the dependencies" and what you're saying - if there's a dependency, it has to be declared, right?


True, but the difference is whether you declare it on a local level, next to the component. [Or in our case in the definition of the component (we have a wrapper).] Or on a global level. The global level is much more fragile and very tedious in my experience. Especially if you want to create different versions of systems like test/dev/production etc


E.g. for dev we can swap out a key-value store with an in-memory version which has different dependencies, but with a local approach you don't notice this


Another thing is that the dependency is declared on a local level anyway (as you are using it in the definition). So the global declaration is just extra and unnecessary work i think


Makes sense or too vague?


we're doing this via aero also


We don't reuse components much, so we've been looking at moving to integrant


Does aero do the dependencies for you?


We have a :dependencies key in the components.


Ah interesting


Do you know a public example of that approach?


Unfortunately not


For dependency resolution, my favorite approach is actually the one taken by integrant - having a special #ref EDN tag / data structure naming dependencies, and building the DAG from that. This way you can have both inline or globally resolved deps in an arbitrary structure


Ok cool. I'll have to try that


(= [{:state :changed,
     :template "procmailrc",
     :config [["start" []] ["end" []]]}
    {:state :deleted,
     :template "procmailrc",
     :config [["start" []] ["antivirus" []] ["end" []]]}]
   [{:template "procmailrc",
     :config [["start" []] ["antivirus" []] ["end" []]],
     :state :deleted}
    {:template "procmailrc",
     :config [["start" []] ["end" []]],
     :state :changed}])


Why it returns false?


ah, I know, sorry!


I have to use set here.


Because order does not matter.


Is spec clever? If I've got function with :pre check checking one argument and then this function calls another function verifying the same entity against the same spec, is spec going to waste time checking it again?


I want to execute function on every item from list. However, this is actually changing the filesystem and ends up as a lazy expression never really evaluated… Is doall the proper way or maybe there's some different construct than currently used map which is not lazy?


there are run! (like map) and doseq (like for)


Is there some idiom for (first (filter ,,,))?


You could use some but then the predicate has to return the original value


Same context: is there a helper that like (fn [pred x] (when (pred x) x))?


no, but I've defined it as "when-pred" in multiple projects


@alexmiller are you excepting GitHub pull requests for the clojure windows installer branch ? I have some fixes to contribute.

Alex Miller (Clojure team)17:07:51

No, but feel free to comment on the ticket


Hi all, I looked for channel dedicate to json parsing but I only found #tmp-json-parsing which doesn’t appear to be active so I’ll ask my question here: Is there a benchmark comparing json->edn decoding with and without converting keys to keywords? I tried googling for a while but got nothing. data.json, cheshire, jsonista doesn’t really matter, I guess results would be relatively similar in all


the main concern with keywordizing is if you will be hard-coding the keys in your logic handling the incoming data, and whether the keys actually make sense as keywords


for example "foo bar baz" and "0" are valid json keys, but are various degrees of bad as keywords (though the keyword function isn't picky)


@noisesmith thanks for pointing these out. However, I’m still interested in the performance overhead keyword introduces when parsing json


I can run the benchmark myself but was curious whether someone already did it


it's negligible compared to creating the data structures


I would be surprised to ever see a situation where keywordizing was the bottle neck that was making json parsing too slow (outside of pathological keys...)


:thumbsup: Cool! Thanks, that’s what I was looking for:)


there was a whole jira thing about it

🙇 8

Interesting issue, thanks for sharing!


guys, can you help with refactror-nrepl? i have this in .lein/profiles.clj

{:user {:plugins [[refactor-nrepl "2.3.1"]
                  [cider/cider-nrepl "0.17.0-SNAPSHOT" :exclusions [org.clojure/tools.nrepl]]]}}
when run lein repl I always get this:
Error loading refactor-nrepl.middleware: Could not locate cider/nrepl/middleware/util/misc__init.class or cider/nrepl/middleware/util/misc.clj on classpath., compiling:(refactor_nrepl/middleware.clj:1:1)
Exception in thread "main" java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.middleware/wrap-refactor in this context, compiling:(/private/var/folders/dd/yjt452yn0zs1hs4_sd077rsm0000gn/T/form-init8768462867645520700.clj:1:8336)
	at clojure.lang.Compiler.analyzeSeq(
	at clojure.lang.Compiler.analyze(
	at clojure.lang.Compiler.analyze(
	at clojure.lang.Compiler$InvokeExpr.parse(
	at clojure.lang.Compiler.analyzeSeq(
	at clojure.lang.Compiler.analyze(
	at clojure.lang.AFn.applyToHelper(
	at clojure.lang.Var.applyTo(
	at clojure.main.main(
Caused by: java.lang.RuntimeException: Unable to resolve var: refactor-nrepl.middleware/wrap-refactor in this context
	at clojure.lang.Util.runtimeException(
	at clojure.lang.Compiler$TheVarExpr$Parser.parse(
	at clojure.lang.Compiler.analyzeSeq(


@rustam.gilaztdinov plugins are dependencies which get injected to leiningen, refactor-nrepl and cider-nrepl are dependencies which need to be present in your project in order to function.


it may be correct to have refactor-nrepl as a plugin, but cider-nrepl almost certainly needs to be a dependency not a plugin.


no, first -- added those plugins for local project doesn't solve this, and second -- I want to have this plugins global, for all my projects


I cleaned all from ~/.m2


cleaning all from m2 is rarely useful, do you understand what he means about using a dependency instead of a plugin? this is code needed in your running process, not the leiningen process that creates it


yes, I understand him) cider and refactor-nrepl needs for development, right? so, why I should add this to dependencies?


I think -- this should work from ~/.lein/profiles.clj globally


plugins are for things that need to load in the leiningen process, dependencies are for things needed in the clojure process. The cider and refactor-nrepl stuff needs to be present in your repl, not the leiningen that starts it


so it's still in ~/.lein/profiles.clj but under the :dependencies key, not the :plugins key


each one should document whether it should be in plugins vs. dependencies checking the docs, they should work as plugins (the source of confusion here being that they are plugins that exist to change the deps in your process, plus set up your repl middleware) one thing to double check is the exclusion you are specifying - if you exclude a dep and nothing else provides it you'll just break anything that tries to use it


i check docs, and all says me to use it in .lein/profiles.clj


right, nobody has questioned thhat


They both should be plugins, the bug here is that refactor-nrepl doesn't play nice with the new cider. Try 2.4.0-SNAPSHOT for refactor-nrepl.

đź‘Ť 4