polylith

onetom 2026-06-09T03:47:56.853399Z

โ€ข 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

onetom 2026-06-09T03:49:36.856139Z

btw, in Hong Kong context IFC means https://en.wikipedia.org/wiki/International_Finance_Centre_(Hong_Kong)

imre 2026-06-09T07:58:05.795669Z

api can be another alternative

2
imre 2026-06-09T07:58:16.367089Z

or just i ๐Ÿ˜›

imre 2026-06-09T07:59:14.236139Z

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

onetom 2026-06-09T08:05:07.312889Z

yes, i saw that recommendation about using bases, BUT their drawback is that other bricks can't depend on bases, only poly projects. right?

imre 2026-06-09T08:09:38.647399Z

yep

2026-06-09T08:31:05.542309Z

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

๐Ÿคจ 1
2026-06-09T08:31:48.910419Z

so you can have a proxy namespace to an interface one if you want to test them or use in other components

๐Ÿ™ƒ 1
2026-06-09T08:33:16.696799Z

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

๐Ÿซ  1
onetom 2026-06-09T11:11:16.140999Z

@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.

imre 2026-06-09T11:17:28.098679Z

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

๐Ÿชข 1