Mine are "helpful" like that too sometimes! 🙂

I think this is a tricky proposition because if you had shared components between any libs, those namespaces would end up in both libs. One way to approach it would be to have each lib as a base, with the corresponding project defining how to build that lib -- with no components.

FWIW, I just finished edits on a doc that talks about just that!: https://cljdoc.org/d/polylith/clj-poly/0.2.18-SNAPSHOT/doc/artifacts#_caveats_on_publishing_multiple_libraries

@U050TNB9F I was considering using polylith for cljdoc at one point... and wondering if it would be a good fit. (maybe bringing the analyzer back into a monorepo for example)

I guess any monorepo that publishes multiple libs would have to be very careful about lib compatibility and interdependence between those libs.

@UE21H2HHD I wonder if, maybe, you want to call out the swappable implementation issue directly in those caveats?

Yeah, that content is still light on the crux, I think.

Side note: In Python, this is a problem that I hadn’t thought about at first. Later on, I developed an option in the Python poly tool to generate a new top namespace during build/packaging on top of the existing structure. Python packages are installed into a ns-folder structure, and will collide/be merged when having the same namespace.