@tcoupland I will try to summon @martintrojer who would be more qualified to answer that. Personally I haven't used joplin so I'm unsure. It was a library we built on our http://OnTheMarket.com project

@tcoupland es is a fast moving target. Personally I'd just re-write all this using a regular http client or a lib based on one, this is more future-proof

we have schemas/migration that work for 2.4+ and 5.x+ using such a lib, this requires just a couple of conditions/switches and it's all dealt at the data level, not api. It's much nicer imho

when I say rewrite, this could mean re-write the joplin module for it

fast moving: by the time we supported 5.x 6.x was coming out, with it's lot of breaking changes

es is managed in a very different way than clojure for sure

with aero, read-config would throw an error if there’s a type coercion on an env var and the env var doesn’t exist (expectedly so), if I have a multi-profile config, how do I deal with this not breaking in environments like dev where these env vars don’t exist and are coded-in as a part of the config? is there a generally a better pattern to deal with a situation like this?