Clojurians Log v2

Hmm I guess this doesn't make sense, because tests are always ran in the context of a project 🤔

Basically I was wondering how to run unit tests from components, no matter if they are used in a project or not

but I don't think that's how poly testing works

i theory your dev project would have most if not all components referenced

poly test :dev perhaps?

that would include bases too

Hmm. You could set up an alias, say, :+bases that contains all your bases and your dev project only your components?

and use :+bases in your repl

Another option is to create a separate project where you include all your bricks, but https://cljdoc.org/d/polylith/clj-poly/0.2.21/doc/testing#include-exclude the bases from being tested.

That's what we ended up doing 🙂

not a bad one

Polylith requires a "top ns" then bases and components. And components must have an "interface" ns. But otherwise, most of what you're suggesting sounds like a typical Polylith workspace. So I guess I'm not really understanding what you're asking...?

core would be a component. mice-overlords would be a base (or perhaps another component).

org.example would be your top ns.

Just making sure I follow - Components cannot have (sub)components, right? So if mice-overlords is a base, does anything inside this ns belong to the interface of that base?

A base does not have an interface

Obviously. Sorry.

I guess I'm still not really sure what you're asking... Polylith has specific conventions you must follow...

I would like to develop both a stand-alone app and a server. I would like to have a structure similar to: org.example.core.user org.example.core.db org.example.core.cli (base) org.example.server.networking org.example.server.api (base) or perhaps org.example.app.core.user org.example.app.core.db org.example.app.cli (base) org.example.server.networking org.example.server.api (base) If I make the top ns org.example I don't know how to create a component with the ns org.example.core.user. if I create a component called user, it will have the ns org.example.user. If the top ns will be org.example.core, I will be able to create the user component, but I will not be able to create a server component (unless I place it inside the core ns). I think I missed something, but I can't figure out how to structure my project to allow for a component not to sit directly after the top ns, and I can't figure out how to create the ns hierarchy without this ability.

All components must have <top-ns>.<component-name>.interface as their primary entry point. The implementation can be in any nses (that start with <top-ns>.<component-name>). That's the rule.

All bases must have nses that start with <top-ns>.<brick-name>

Namespaces have no "hierarchy". The ns foo.bar.baz has no relation to foo.bar (the directory structure overlapping is coincidental).

At work, we have about 200 bricks (bases and components) and about 24 projects. So we build two dozen standalone apps from over 175 components.

That was very informative, thank you. I think this is exactly the part I was missing - (that) "Namespaces have no "hierarchy". The ns foo.bar.baz has no relation to foo.bar (the directory structure overlapping is coincidental). " Thank you very much.

This was all answered in the other thread which is why I posted my comment here. Not using threads just duplicates work for people!

It's better to use threads so there's a single clear place for folks to reply.

> Can I make components that are not directly under the top-level namespace? No > org.example.server.core.networking > org.example.server.service You normally don't put code directly in each service (project) even if it's allowed. Instead, each project is just a set of bricks (often one base and a bunch of components). > org.example.client-app.core.user If org.example is the top namespace, then you can create a user component that will live in the org.example.user namespace. To be correct, org.example.user is the name of the interface but we often use the same name of the interface and the component (you will notice that when you run the info command). > org.example.server.api (base) If the top namespace is org.example then this base will live in org.example.api or if you name it to e.g. server-api it will live in org.example.server-api. All bricks will live at the same namespace level, directly under org.example. Your deployable projects (`development` not included) are just a set of bricks, often with a single base and a set of components. The base will delegate to interfaces (e.g. org.example.user) via their interface namespace that you import (e.g. org.example.user.interface). This is the Polylith's way of organising code.