Alex Whitt

Any thought on these helper functions? I've come to the point that I have had to split them off from my BACnet repository into a separate library to share between...

I'll add that `:duct.module/foo` *does* show up in the system as a function, but it does not apply that function to the system config.

OK, understood! So for configuration that differs between profiles, should I just be changing top-level keys instead of module options, like below? config.edn ``` :duct.profile/dev {:foo/bar :dev-value} :duct.profile/prod {:foo/bar :prod-value}...

Got it, thank you! My use case really is not any more sophisticated than the example I provided, but I sadly can't share any real code until I can convince...

Ah actually I lied, this does turn out to be slightly inconvenient, because my :foo/bar key has some simple logic attached to it (like a default value, or casting the...

I had, and I just reviewed the information I could find on it. It sounds like, as you said, modules can sometimes be replaced entirely by profiles+prep-key? But I'm unclear...

I really have been striving to convey the "why"... I'll try to boil it down to a list of needed features: * I need a central thing to include that...

This seems like it would be a totally normative use case concerning how modules are to be developed... again, your web module seems to do some sort of magic to...

Thank you! Here are my questions: ### Option 1: This seemingly moves the dev/prod decision-making to the module itself, rather than the configuration. So the module developer can build in...

Is it more than just resolving all profiles first, and then taking that config and resolving all non-profile modules next?