Clojurians Log v2

An alternative is to support more than one top namespace @pavlos, e.g. not only se.examplebut also <http://se.example.se|se.example.se>, <http://se.example.de|se.example.de>or maybe se.example and de.example, and so on, with the limitation that the bricks need to be unique across the whole workspace. The drawback is that it would complicate the code, the number of tests that needs to be created, the documentation, and so on, so I need to understand the use case better to understand if it’s worth to pay that price. We have earlier rejected ideas like “sub workspaces” that could support having both an se/user component and a de/user component. We try to keep things as simple as possible, but at the same time try to listen to the user needs!

What is the largest single Polylith workspace you’ve worked with so far?

Both in terms of the number of bricks — the “width” — of the repo and in terms of the number of lines of count — the “depth”?

@furkan3ayraktar’s Scrintal project had 68 bricks last time I asked, and 7 projects. I don’t remember exact how many lines of code, but it’s not huge, maybe something between 10,000 and 20,000 loc.

@tengstrand I agree that having multiple top namespaces would complicate things a lot. I was thinking more along the lines of having an additional, optional map in workspace.edn to manually override interface/api namespace discovery. Or a single vector that would also absorb :projects ? Not sure which one is better... I created a https://gist.github.com/PavlosMelissinos/6194866cd48354a1ae73a4c8594f1e46, based on the polyfy/polylith repo Not saying it's a sound idea, mostly looking for opinions. It's a good exercise in software design for me regardless 🙂

Hmm. I’ve looked at the gist. If we take Suggestion A as an example. Firstly, there is no magic about the core namespace for a base. You are free to use any namespace after e.g. se.example.my-base you want, e.g. se.example.my-base.api . I don’ know if I understand what you want, or what problem you try to solve. Am I correct if I say that you want to “move” e.g. the my-base base from se.example.my-base to e.g. <http://se.example.my|se.example.my>.base ?

> you want to “move” e.g. the `my-base` base from `se.example.my-base` to e.g.  `se.example.my.base` > yes, that's correct > there is no magic about the `core` namespace for a base [...] > You are free to use any namespace [...] > Oh ok, I didn't realize that, sorry. So it's solved for bases but what I'm describing is still the case with components, right?

When you “So it’s solved for bases”, then I still don’t get what you mean. I also need to understand why the base or component can’t live where they already live, under the top namespace and what the use case is, so it would be great if you could try to clarify that one more time!

Ok let's ignore bases for a minute. The namespace of a component's interface has to be under: <top-namespace>.<component-ns>.interface component-ns can be something like user-input or user-config but it can't be user.input or user.config Is this statement correct?

Yes, that’s correct. As it is now, the pattern is <top-namespace>.<component-interface>.interface . What you need to do is to put the implementing namespaces under e.g. se.example.invoicer.<any-ns-except-interface>.<optional-sub-namespaces> and the interface under e.g. se.example.invoicer.interface.<optional-sub-interface-namespaces> . With this pattern you are free to organize both the implementing code and the interfaces wherever you want. Will this solve your problem?

All of the implementing sub-namespaces have to be part of the same component though, right?

Yes.

So if you have two components e.g. invoicer1 and invoicer2 that implements the invoicerinterface, and want to share code between them, then that code needs to go into a separate component and be accessed through that component’s interface.

Thanks, that clears it up a bit for me. It feels to me like polylith makes too many assumptions about namespaces but it's hard to get my point across without a non-contrived example. I'll try to think of one before I take up any more of your time 🙂