Fork me on GitHub
#clojure-uk
<
2019-07-29
>
rickmoynihan08:07:03

Integrant + aero is quite a good combo, and one I’ve used quite a few times — though I find aero a little too expressive in this use case. I personally prefer duct, though its config layer hasn’t yet been fully extracted from its web stack. I think integrant + meta-merge + a few reader tags to inject env vars into configs is pretty much all you need — then structuring those configs as a series of profiles/overrides.

dharrigan08:07:02

I think so too. I've got aero + integrant working now

dharrigan08:07:10

and seeing how that goes

dominicm09:07:43

refs are pretty dope for configs too, they're by far the hardest part of aero to implement too.

rickmoynihan10:07:05

yes they’re really useful. Though less so when combined with integrant, as you’ll already be using #ig/ref

maleghast10:07:13

Morning All 🙂

dominicm12:07:37

#ig/ref is different from #ref though. One is post-init, one is pre-init. They don't overlap for me.

rickmoynihan12:07:11

yes they evaluate at different times — but I’ve found rather than mixing them you’re normally better just lifting the #ref’d value to the top of the system and #ig/refing them as a “value component”

rickmoynihan12:07:29

there’s usually no need for two kinds of ref

dominicm12:07:25

That's an interesting approach, one I've discouraged! So you essentially have an inherited component which is clojure.core/identity which you pass things which you need to reference?

rickmoynihan12:07:31

Precisely… Usually I do something like:

(defmethod ig/init-key :project/value [_ v]
 v)
Then define in config:
{[:project/value :shared/thing] "the value"
  :some/component {:value #ig/ref [:project/value :shared/thing]}
}
Worth mentioning also if you’re using duct you have this already with the :duct/const component.

rickmoynihan12:07:00

I’m a big fan of aero and use it a lot — but mixing it with duct is overkill, and mixing it with integrant makes some amount of sense — but I’ve found it makes things harder to reason about. If you do to the above you don’t need aero for #ref, and what does that leave? #join #env #or not much else — all of which can implemented pretty trivially in a single line if you need to add them yourself.

rickmoynihan12:07:58

I think the main problem is #ref introduces an additional dependency between keys / components — which makes it harder to refactor things… it can also introduce scope problems, as it doesn’t see all #includes. I suspect that’s why aero recommends using a single configuration file; though I’d really much rather many with clear evaluation/precedence semantics; and scoping rules.

dominicm12:07:10

what do you mean it doesn't see all #includes?

rickmoynihan14:07:33

I could be wrong about this… but are #includes resolved before #refs? i.e. do #refs have scope over the fully resolved tree, or just the file they’re in? Either way it’s these kinds of issues that cloud the semantics, especially when combining with other systems.

dominicm14:07:22

fully resolved tree. Anything else is a bug.

👍 4
dominicm14:07:33

(like the set one I think it was you who reported)

maleghast14:07:57

I am following along with this, with interest... For

maleghast14:07:11

we don't have all of our config only in the aero config, we have namespace that manages injecting ENV VARS for Heroku deployment, but...

maleghast14:07:01

...for my own purposes I want to re-wrap my head around having the web listener definition just there in the config, even for a much more complex app, like the way that an Edge app comes out of the generator...

rickmoynihan14:07:37

Not sure I follow… do you mean you load an aero config, than manually assoc (System/getenv "VAR")s on top? Also are you using integrant?

rickmoynihan14:07:55

ugh slack playing up

maleghast15:07:01

@rickmoynihan - I am not confident that I can explain it in Slack; don't worry too hard about it, suffice it to say that in order to get Edge to play nicely with Heroku we needed to make some deviations from the "standard" approach 🙂

dharrigan15:07:26

ah, the joy of repl-driven development 🙂

dharrigan20:07:52

Can anyone recommend a good documentation tool that produces lovely asciidoc generated content? A nice version of JavaDoc, but for Clojure?

seancorfield20:07:50

@dharrigan Like the stuff http://cljdoc.org is based on? Pretty sure that supports asciidoc as well as markdown?

dharrigan20:07:11

Yes, but I don't want to publish to clojars and it seems that's it's real intent

seancorfield20:07:22

You can run it locally.

dharrigan20:07:25

this is for internal documentation - or have I picked up cljdoc incorrectly!

dharrigan20:07:37

It's not very obvious 🙂

seancorfield20:07:49

You can set up an internal instance and import projects into it.

dharrigan20:07:56

ah, so you have to run an instance of cljdoc on a server somewhere, to host your content?

rickmoynihan10:07:33

curious how you get on… I’d like to build docs for all our private clojure repos

dharrigan11:07:45

sure, will report back

seancorfield21:07:03

Feel free to drop by the #cljdoc channel and ask for guidance if you want to go that way but I was doing some bug chasing on it and ran it locally and was importing various projects from disk into the local instance -- and then browsing that local server full of newly-generated docs.

seancorfield21:07:43

I can't remember if you can get it to export the generated docs from a local instance or whether it always needs to actually run...

seancorfield21:07:04

But even without that core engine, you could probably co-opt the doc generator part.

dharrigan21:07:08

okay, will ask around on cljdoc