Fork me on GitHub
#polylith
<
2021-11-12
>
crimeminister18:11:13

Are there any conventions established around sharing polylith components as separate repos? Thinking of using a naming scheme like clj-poly.foobar

seancorfield18:11:13

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.

seancorfield18:11:40

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

seancorfield18:11:27

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

crimeminister19:11:56

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.

crimeminister19:11:12

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

seancorfield19:11:51

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

seancorfield19:11:39

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

seancorfield19:11:34

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

crimeminister19:11:03

Tremendously helpful, thanks a lot!

tengstrand10:11:20

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.

seancorfield20:11:41

Status update on our Polylith migration -- we're up to 35 components now and climbing (I've declared today "refactor Friday" so I'm slowly pulling apart legacy subprojects and moving code into components):

projects: 18   interfaces: 34
  bases:    6    components: 35

polylith 8
🚀 5
Ben Sless17:11:08

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?

seancorfield17:11:53

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