Clojurians Log v2

This is the main problem I've ran into with poly as well. I have this exact shape in a Polylith workspace: two components, facts-file (simple hardcoded data in files, good for REPL and tests) and facts-rama (more complex Rama backed store, for production), intentionally provide the same omni.facts.interface namespace so the active implementation is selected by classpath/profile. Consumers use requiring-resolve against the interface and stay backend-neutral, but that means the implementations cannot both be on the default workspace classpath. As a result CI has to run multiple classpath variants, e.g. neutral Polylith tests plus test+facts-file and test +facts-rama. It works, but it feels subpar because the polymorphism is outside Polylith’s normal component/project model and leaks into alias/CI orchestration/Production system wiring

And while that's not a huge problem, it's only because I don't have that many components (specifically polymorphic ones), but I wouldn't want to deal with the explosion in combinations when having multiple of these

OTOH I have to admit, I don't have a better answer to this problem either

you could perhaps solve this with another layer: facts-file: omni.facts-file.interface facts-rama: omni.facts-rama.interface facts-dev: omni.facts.interface - uses runtime polymorphism to dispatch to facts-file or facts-rama facts-prod: omni.facts.interface - uses facts-rama

Would you say those last two are profiles/aliases or actual components?

components