Yes, that's the reason (`poly/` is just a convention). As long as you don't share code outside the workspace, you can use any valid prefix.

in our project, we use the interface name

Yes, that should work too, because interface names are unique per project.

ok, so this is kinda DI on namespace level? in comparison to DI on argument level when we could rely on actual definterface (including system's component DI being passed through)

On namespace level yes, but they are not injected. The bricks become available when we specify them in a project, in the same way we specify libraries (which are also not injected). I tend to see bricks (and libraries) as living side by side. I try to explain this in the Composable section in https://medium.com/@joakimtengstrand/understanding-polylith-through-the-lens-of-hexagonal-architecture-8e7c8757dab1 blog post.

Here we illustrate how bricks are used across projectsthanks for the article, however interestingly I noticed a "development" project after this line. does it mean there should be no toplevel deps.edn at all (but projects/development/deps.edn instead)?

The development project is configured in ./deps.edn and not under projects as other projects.

Bases can depend on other bases, but that's quite unusual.

ok, got it, the projects/development/deps.edn -> ./deps.edn was forced by something like projectile looking for repl's deps.edn and trying to find files in this subfolder only? or any additional more important reason?

and second question - suppose we really want DI on ns level and use different components (`compA` and compB providing ns.comp.interface) should we have identical fn signatures in compA/src/ns/comp/interface.clj and compB/src/ns/comp/interface.clj ? (in short there's no defprotocol on ns-level which declares interface once)

tools.deps and other tooling want it at the root.

Yes, the signature has to match. See https://cljdoc.org/d/polylith/clj-poly/0.2.19/doc/interface#one-interface-in-multiple-components example.

thanks for detailed reply and usecases Sean, I got it, brick != dependency and not self-contained, basically you're also talking about namespace-level-DI as well let me generalize the use-cases: • for i18n making and passing a "translator" interface would be too invasive? • for http-client we cannot get a usual DI because there's no interface and classpath for projects and repls should be different anyway

The specifics for i18n is to be able to create an app that has no JDBC or database-related dependencies in it at build time so it produces a minimal JAR file.

And for http-client, the hato-based version will not even load on JDK 8 -- but the clj-http version will load on both JDK 21 (11+) and JDK 8 so we can test both implementations on the more recent JDK if we wish -- but we do not generally want clj-http on the classpath because of its assumed dependencies -- so both implementation choices are build time by necessity.