In the real world example app we put them in the interface, but in the sub namespace interface.spec, e.g. https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app/blob/master/components/profile/src/clojure/realworld/profile/interface/spec.clj.

Yeah, I prefer it this way so it’s very clear when used somewhere else,. I prefer to have a spec implementation namespace, usually, top-ns.component.spec and a sub interface top-ns.component.interface.spec, just like in the realworld example.

Yeah, I would favor <top-ns>.<component>.interface.specs (it's more common for Spec nses to be named specs than spec based on what I've seen out in the wild). But only for the Specs themselves -- and perhaps some very small, self-contained predicates that they alone depend on -- any associated or supporting code should be outside any interface.

I see it's mentionned here https://polylith.gitbook.io/poly/architecture/interface

I don’t have much experience with submodules (I talked with Furkan also). Maybe someone else has.

> can I use git submodules as components with polylith It's possible, as long as each submodule points to a repo that only contains a single polylith component. Why would you want to do that though? It kind of goes against the point of polylith. a submodule is basically a soft link (pointer) to the commit sha of another repo. It even has its own remotes. Polylith offers a way to manage multiple projects in the same repo. I don't see how those two goals can be reconciled.

I suppose it would be neat to be able to get components from other polylith repos by pointing each submodule to a path in the target repo but git doesn't support that afaik (yet). edit: of course you can do all that with CLI tools.

the reasoning would be to make it easier to integrate projects that aren’t under full control of the polylith workflow into it. for my usecase I’d like to have a polylith project with my own stuff, but put in a lib I’m only contributing to as a component.

I see... If I'm not mistaken, in order for that to work and assuming that you're interested in using the poly tool, the library you're integrating should still adhere to the "rules" of the polylith workspace (e.g. there has to be an "interface" namespace, or whatever you've defined it as in your workspace.edn, the top namespaces should match, etc). So yeah, as long as the library is disciplined enough to do the above, I think you'll be fine.