Actually I realise that 2 will make 1 less frustrating and vice versa 😄

The poly tool understands the interface namespace and ensures that components do not depend on each other freely; instead only use their interfaces. As a result, the workspace is less entangled. The poly tool supports using interface prefix. You can create a directory named interface (or ifc, in your case) and place namespaces inside that directory. The names paces become x.y.z.ifc.my-ns-1, x.y.z.ifc.my-ns-2 etc.

Regarding 2️⃣ I do use the directory prefix. I'd prefer a file prefix as it makes search easier (that's the nature of the post). I would type in mycomponent... in emacs search. Instead I type in ifc... and get a wall of entries (due to me often relenting on 1). Regarding 1️⃣ I will then simply have to endure a large number of errors, where I don't regard adding the boilerplate as adding value to my life. My life would be better if there was a switch on specific components to hide those errors.

Apologies! I see you mean include the ifc in the directory. I read it wrong. I'll have a think.

Thanks

@U03B2SRNYTY You can put the full implementation in the */ifc/*.clj* file to avoid "boilerplate" if you want.

At work we have a few interface.clj files that contain the implementation instead of also having a impl.clj (but mostly that's a result of refactoring from non-Polylith code and we just haven't gotten around to separating out the actual interface from the implementation).

@U04V70XH6 Completely agree about full implementation in the ifc file, and with the suggestion above can have a meaningful name. What I liked about Clojure development compared to Java was the abandoning of an overly nested package structure. Clojure namespaces catered to many exposed symbols in very flat directories. The equivalent were deep nested directories in Java at my previous enterprise stack. Having an ifc directory feels a little like a regression to that state. I'll have to adopt tree instead of ls...

We have 200 deps.edn files, just to give you a sense of scale. Most of our components are just two src files: ws/<component>/interface.clj and a corresponding impl.clj - we tended to have more nesting before we moved to Polylith.

@U2BDZ9JG3 Morning. How do you get poly create.. to create an ifcdir instead of the reverse? The default behaviour obscures the option.

The create command is not very flexible. I'd love a way to change the layout/structure of what it produces by default. Things I change in every component immediately: • remove resources (and update :paths in deps.edn) • remove entire test folder • add copyright to interface.clj Then I code for a while in the REPL, maybe create impl.clj and refactor. • run a shell script to generate stub test files (without failing test, with our copyright, without requiring clojure.test, with a (:require [<interface-ns>]) ; :as sut line in ns (SUT is an old, old habit from my early TDD days many years ago -- so all tests always have (sut/my-fn ...) as the system/service under test). I think it would be really nice to have templates for new bases, components, and projects, either in .polylith/templates/... in the workspace or ~/.config/polylith/templates/... in the user home directory. I've been tempted to add something to deps-new for this (`clj-new` has a Polylith template that is closer to my preferences but it's a "whole project" creator -- deps-new is more amenable to adding features to an existing project).

I've seen sut before. Source under test, correct? 😂

Source/system/service, yeah.

I have a bad habit of not reading long lines, completely.

I picked it up many, many years ago and can't shake the practice...

(yikes, XP is about 30 years old at this point)