Clojurians Log v2

:thumbsup: Thanks for confirming. Regarding that behaviour; I think it makes sense; but I think in some cases there might be more nuance to it. For example, I think I’d like to tell duct/integrant (presumably through a new option/function to preserve backwards compatibility) to still allow any refsets to be empty; but to also guarantee that any keys which are referenced via an #ig/refset are instantiated automatically. i.e. to include (depth-search refset? sys) as keys to ig/init. The reason I’d like this is that right now I have to maintain a list of all derived-keys, and remember to supply them in every context we start the app from (each deftest, main, dev/repl, etc). It’s not a huge problem, but every time I’ve added a refset I’ve forgotten to include the key in the keys provided to main; which is more selective than our dev/repl environment because it doesn’t want to start everything). And I’ve only discovered these problems when I’ve built and deployed the app to a staging env. At the minute I think I’d always want this behaviour, not the current one. I can and will do the above to prevent this from happening again however I wonder if it’s a more sensible default for others too?!

Currently Duct relies on refsets working the way they currently do. In fact, that’s part of the reason they were added. Refsets allow for ordering without automatically pulling in keys. I’d need to consider how best to solve this without breaking existing behaviour, but this may take a while, as my focus is currently on Ring.

Yeah no rush on my part, I can work around these issues… I’m really just raising them as hypothetical ideas. I’m curious about what you think would specifically break though? Imagine the new behaviour was opt in; would existing modules in duct core be broken if you instantiated them with this option?

Modules rely on refsets being able to be empty in order to allow ordering. They might work if a refset automatically included all its keys… however, I’m reticent to do that as it means removing existing functionality. I can’t remember if any existing modules or components rely on it.

ok that makes sense… In principle I guess modules could still use the existing way; whilst the components in the prepped config could opt into the initialising of refsets. I can see why you might not want to do that though.

I see the current mechanism as being useful for modules and for prep-key in particular. They allow you to say “if there is a key K, include it here”.

So you can have optional behaviour such as, say, a logger or some kind of debug tracer.

But it’s also not too late to change this behaviour either. For example, by having something like #ig/refset {:key :user/foo, :opt? true}

(ig/refset :user/foo {:opt? true})

Is it really :opt? true? here btw? As that is already the default (existing behaviour). Shouldn’t the option be more like :auto-init? true?

Yes, probably. I’m actually now thinking it’s might be better not to add init options to refs.

Well it’s just an arbitrary flag right? It won’t actually do the initialisation; it’ll just flag that it should be included by ig/select-keys and/or some other arbitrary function/pred ?