hi @gardnervickers I've spent some time this morning having a more thorough review of your aero changes. I've been able to replicate most of the functionality of transforms without needing the abstraction and I feel that transforms, while useful, can be explicitly achieved by the user outside of aero. Anyway, I've created a branch (gardner) with a number of commits on that explain my thinking here. I've also renamed #cond to #profile and done some other work. I think I've mostly been able to keep the functionality you've added.

Also, see the README on the branch for more explanation

I'd appreciate your thoughts and comments - I don't need to merge this to master urgently so we've got some time to mull it over

@malcolmsparks: I think I like this new approach a lot better, we’ve seen arbitrary transforms make it too tempting to write what should be code in edn. One more addition I’d like to make is that if the ^:ref resolution ends on a map/list/vector we run the postwalk step on it again, this is because ^:ref is not recursive unless it ends on another ^:ref. This will not resolve correctly currently.

{:user ^:ref [:gardner]
 :gardner {:favorite-color ^:ref [:color]}
 :color :blue}

@gardnervickers: the problem with encouraging applications to post-process config is that it then makes the configuration not 'readable' in its own terms - one has to know both Aero and how the application is processing the config to reason about configuration. If you're only supporting one app, that's fine. But what if you're supporting many such applications (as happens in larger orgs)

Agreed

We've had some difficulties with systems that do clever things, like compute port numbers, which while clever (avoiding port conflicts), make reasoning about the configuration much harder

I think configuration should be something (ideally) that one can reason about (in its own terms) rather than have to reason about the entire system as a whole - well, that's the aspiration

I'm trying to figure out your point about the snippet not resolving - not quite sure I follow your point about rerunning the postwalk, can you explain again?

(read-config (new java.io.StringReader
                  "{:user ^:ref [:gardner]
                    :gardner {:favorite-color ^:ref [:color]}
                    :color :blue}"))

results in

{:user {:favorite-color [:color]}, :gardner {:favorite-color :blue}, :color :blue}

ah, I see, that's wrong

it should be

{:user {:favorite-color :blue} ...}

I'm struggling to implement this - I'm going to leave it as a TODO

I'm thinking of removing the deprecated stuff and just going with a 1.0.0

I'll do a 1.0.0-beta1 I think

Ok

I've fixed the issue by doing a postwalk twice - not quite sure why that works but I've tested it on a few cases and it seems to work

Deployed to clojars as 1.0.0-beta2

I've added a test for your example:

Seems to work 😉

We're using aero on https://juxt.pro and I must say it's getting quite a workout!

temp fix applied