Clojurians Log v2

@weavejester: I’ve only just noticed that duct.core doesn’t actually depend on your meta-merge library, but instead has forked its implementation here: https://github.com/duct-framework/core/compare/f64981c438cd3d717b596f71bfb0c16e4f3304f5...2e943c5866219dad7828abc79bc2a2aac7894d7b I’m curious what the reasoning is, and what the differences are between the implementations?

I’d always assumed it was a normal meta-merge

@rickmoynihan It’s a superset. It includes some extra metadata options (:promote and :demote), and some functions/data-readers that allow primitives to be marked as :replace and :displace, since normally metadata can’t be applied to primitives like integers or Java classes like strings.

I wanted the meta-merge library to be a straight clone of the Leiningen logic, and I also wasn’t 100% sure about the extra merge logic I added to Duct.

Cool I suspected something like that. I’d been augmenting duct with some custom stuff we have, and relying on meta-merge as a transitive dependency. I’d assumed meta-merge was supplied by duct, but it tuns out it was a different library bringing it in. I’ll port to using the duct implementation, as I’d really like to ensure it’s compatible.

Thanks for the explanation :thumbsup:

No problem

are you 100% sure of the extra merge logic now? 🙂

I’d need to think about it; but even if I was 100% sure, I still think I’d keep them separate so that I could add experimental stuff to duct.core.merge that I wouldn’t want to add to meta-merge.core.

I’m happy with duct.core.merge in the context of Duct.

I just don’t know if it’s useful outside of that context.

Cool. FWIW I think you’re right. I was just curious what you meant by 100% sure.

Thanks, makes sense. I think we’ll probably stick with a depth approach where we validate the configuration statically (not checking the values of env vars and component refs) and then dynamically via pre-init-spec at runtime and when running dev and test systems.

Is anyone working on clj/deps tooling for duct?