Fork me on GitHub
#polylith
<
2021-11-09
>
yenda12:11:29

https://polylith.gitbook.io/poly/architecture/project > All keys must be unique, and a good pattern is to prefix them with poly/ followed by the brick name, Why is it a good pattern to prefix bricks with poly/ ? As opposed to eg workspace-name/

tengstrand12:11:12

Consistency has a value by itself. If everyone prefixes bricks with poly/ then it will be easier to recognise the Polylith related aliases + that the pattern can be used by tooling.

vemv13:11:18

wouldn't it be cleaner though to use megacorp.poly/foo ? that way it is clearer that the keyword is under $megacorp's control, i.e. I'm not using an internal poly thing, presumably with a specific meaning

vemv13:11:45

that seems part of the point of ns-qualified keywords tbh - saying "this is mine, it cannot clash with something else"

tengstrand13:11:04

The idea with prefixing with something shorter, like poly, is that it is easier to read in my opinion. But if you prefer the longer prefix, I think that should work too.

vemv15:11:41

perhaps that one is easier, but which one is simpler? :) in practice we were slightly hesitant about this name / its implications, so perhaps a simpler name would avoid making one spend time wondering. Maybe you can add As long as the name is unique, you are free to choose any name/prefix - they don't have a special semantic for Polylith. ?

tengstrand15:11:20

Yes, I can add that!

🍻 1
tengstrand15:11:00

I now remember that we suggested that bricks could be recognised by the poly/ prefix in https://github.com/cursive-ide/cursive/issues/2554 issue (at the end). I understand that this could be configurable, but that would also add complexity, so for now I wait till this issue has been fixed before taking any decisions about this.

seancorfield16:11:26

Since external libraries should be using qualified group IDs (I know a lot aren't -- but they should be!), using unqualified group IDs for internal (local) deps makes sense to me. And as long as no one uses poly as a public group ID (unlikely at this point, I'd say), then using poly/whatever for bricks seems like a good way to highlight "this is a brick dependency" -- and that works particularly well for us at work as we migrate code into Polylith, since we were using worldsingles as the unqualified group ID for all our legacy subprojects so now we have poly/thing for migrated stuff and worldsingles/other for unmigrated stuff.

👍 4
vemv17:11:03

megacorp.poly/ or even megacorp.poly-brick/ might be a desirable middle ground, which could plausibly still work for the Cursive thing while still being an explicit, guaranteedly-unique name. Anyway that's just my humble input, let's see how the linked issue gets solved 👀

seancorfield17:11:56

It's funny how everyone always pushes back on Polylith naming guidelines instead of just trying it out and seeing how it goes. It's like the ultimate bikeshedding... 🙂

👍 4
polylith 1