Clojurians Log v2
polylith 2026-06-09
• we have some datomic transaction functions defined in polylith components.
• they have to be referenced in transaction data with their fully qualified symbols.
• they have to be defined in .interface namespaces though, to expose them to polylith bases.
• that makes the already long, qualified tx-fn names significantly longer, degrading readability considerably
1. is there a way to exempt such function from under this convention somehow?
2. has anyone came up with a circumvention of this inconvenience?
3. do poly users typically redefine these verbose conventions in real-world systems? if yes, what are popular alternatives as a synonym for interface? i think the docs mentioned ifc
btw, in Hong Kong context IFC means https://en.wikipedia.org/wiki/International_Finance_Centre_(Hong_Kong)
or just i 😛
on 1 - if you can put them in a base (perhaps by potemkin import) you can use shorter namespaces, bases are less restrictive in this sense
yes, i saw that recommendation about using bases, BUT their drawback is that other bricks can't depend on bases, only poly projects. right?
yep
I think you can put the transaction functions or refer to them in a namespace with whatever you like as long as you don't require this namespaces in any component. I did this for a different use case and polylith doesn't complain
so you can have a proxy namespace to an interface one if you want to test them or use in other components
Also Polylith doesn't complain if you have an "illegal" inline require . So not generally a good practise but this way you can bend the rules a bit
@jeroenvandijk thanks. very interesting suggestions.
the (require 'tx.fn.ns) is quite naughty 🙂
but at least we can have an explicit indication of the code dependencies that way, which both humans and i assume LLMs can benefit from too.
hmm. If you only need the function names in the other component, you could create a function in the interface which returns the fully-qualified shorter symbol of the real function