Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2024-02-01

Channels

#polylith
<
2024-02-01
>
imre12:02:42

Polylith documentation and examples suggest using poly/<brick-name> in deps.edn files to refer to bricks. I think this is an anti-pattern - if a project in your workspace ends up (even transitively) git-dependent on a 3rd party lib which itself is developed and distributed as a polylith project then the bricks used by that 3rd party lib might collide with your own. Say you have a poly/string-utils brick and the 3rd party lib also has a poly/string-utils inside. Either tools.deps is going to complain or you'll likely start getting namespace/function/etc not found errors.

Patrix12:02:44

I've always assumed poly was only used because that was a name they chose; my project uses its own prefix like patrix/<brick>

imre15:02:02

I'm not sure now but I recall this pattern used to be recommended some time ago

tengstrand15:02:14

> I'm not sure now but I recall this pattern used to be recommended some time ago Yes, we suggest this naming pattern in the documentation. I understand now that this could cause problems. Maybe we should suggest that people prefix their bricks with e.g. the workspace name (or similar)? Or at least mention this risk.

imre16:02:19

AFAIK all these names are treated the same way as groupid/artifactid by tools.deps on a global level so one should try and keep them unique especially if one publishes artifacts for consumption from the workspace or plans to depend on artifacts published from a polylith repo. workspace name could be an option if it's unique enough - that's what I used with polylith-kaocha However, if you really want to be on the safe side, then perhaps your-group-id.workspace-name/brick-name

👍 1
seancorfield19:02:44

I followed the Kaocha runner's example in my runner (so far the only library I've published, built with Polylith): 

polylith-external-test-runner.bases/external-test-runner-cli {:local/root "../../bases/external-test-runner-cli"}
        polylith-external-test-runner.components/external-test-runner {:local/root "../../components/external-test-runner"}
        polylith-external-test-runner.components/util {:local/root "../../components/util"}}

seancorfield19:02:39

It probably would be good for the documentation to mention that "lib names" (which is what I believe tools.deps et al calls them) should be globally unique for projects that are intended to be used as libraries (it doesn't matter for applications).

👍 1
✅ 2
imre19:02:05

As long as you aren't (unless by intention) shadow the lib-name of a dep of that application

imre19:02:36

Can't remember why I used the .components/bases suffix now btw