Can you elaborate? A Polylith workspace is going to have a configured "top-ns" and all namespaces in that workspace are going to include that.

You can publish a library from a project in a Polylith workspace and that can be used from any other Clojure projects.

(and you could have the library's api in projects/<library>/src under "any" namespaces you wanted I think?)

Useful info, thanks! Will bear that in mind as I try sharing a bit of code. With my question I was thinking less about technical details and more about community conventions around e.g. naming, discovery. In other words, if I see a GitHub repo named clj-poly.foo it's perhaps a hint that I can expect to find it organized according to component conventions, e.g. with a separate interface.clj and implementation namespace, etc.

Perhaps sharing an individual component in the way I envisaged is not particularly useful, and sharing as a project library has more utility; I am still at the foot of the polylith learning curve. 😄

I think a "component" is something physically in your workspace. Something "shared" is a library and is accessible via a dependency.

A component (and a base) is decoupled from any sort of deployment. A project is what defines how a set of bricks should be assembled for deployment -- for "sharing".

You can already depend on a specific project in a Polylith-based github repo, via a git dep and :deps/root -- that's how the :poly alias in a project can be set up (or how poly itself can be installed as a CLI tool).

Tremendously helpful, thanks a lot!

About @U04V70XH6’s question. Yes, you could have a top namespace com.my.company and then include another namespace from projects/src/com.another-ns that delegates to the bricks that live in com.my.company. In the documentation we just say that we don’t recommend adding functionality under the project’s src directory, but this could be a useful use-case.

Has there been a change in the way you break them apart since you've started? Any notable conclusion, shifts in approach, or things to keep in mind going in? Any change in perspective?

Not really. Nothing beyond what I blogged about in terms of naming, modularity, and dependencies.