Clojurians Log v2

in our project, we use the interface name

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

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.

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.

Since you @'d me... > but if I comment it out this single line, I'm still able to run clojure -M:dev -m usermanager.web.main and the app works Because :dev is how you specify the development project and it has "all" the dependencies defined in it. You could also run it via cd projects/usermanager && clojure -M -m usermanager.web.main > imo it's a bit error-prone and non-intuitive when you try to think about components as dependencies Depends on your mental model. Polylith talks a lot about "bricks" and assembling projects from those "bricks". At work, we have some components that have multiple implementations and the project decides which implementation is used (at build time). The development project can be run with any combination of those implementations but, because it is a build-time decision, you use aliases (`:+default`, etc) to tell the Clojure CLI which implementations to use for building the classpath, that is then used to run your project. Not having the (implementation) dependencies hard-coded in the bases or components is the key to making that possible. For example, we have an i18n component that has two completely distinct implementations: one uses a database, the other uses a local JSON file. We have one project that selects the JSON-backed version at build time to produce an app that can be run locally by our UI/UX folks so they can build out new HTML templates and provide the text strings in a local JSON file. That same component (interface) means that all the code that interacts with translations can work identically with both implementations, which improves reuse. We also have two implementations of our http-client component: one using hato that depends on JDK 11+, one using clj-http that can be run on JDK 8 -- because we have a single project that represents a legacy application that cannot run on JDK 9+. To give a sense of scale, we have 23 bases, 22 projects (plus development), and 162 component implementations, with 145k lines of Clojure altogether.

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.