I'd personally prefer to be able to jack in on any file in the repo, and have it use the polylith root dir instead of the brick's root

Probably the idiomatic solution involves setting a .dir-locals.el with a fixed command Although I haven't used Poly for a while

How are you liking the polylith-life, @U01GQNJFP6U?

Liking it a lot so far!

Ooh yeah .dir-locals is probably the way to go thinking about it, I'll have to to find the cider command that defines the fn used to jack in

In a customer project we have a “root level” deps.edn with a :dev alias that adds extra-paths for all bases and components. Originally this was just a hack for Cursive users to make it work but maybe as a coincidence (?) it makes jack-in work “as expected”.

We’ve been using Polylith over a year there. I have mixed feelings. I like some things but others not so much.

Which things do you not like so much @U6N4HSMFW?

I still don’t get the point of base wrt. components. I’ve read the docs several times and implemented several bases but I fail to see the value. poly test is crude and output is horrible. Recently it’s become possible to use kaocha as a test-runner which improves this. Interfaces introduce boilerplate.

@U6N4HSMFW if you have suggestions, questions or even just complaints the folks over at #polylith are very receptive to feedback and quite eager to help 🙂 (I haven't used polylith extensively but I share some of your concerns)

I view the components as simple libraries, and bases are the actual "business" applications which leverage the components

re: interfaces, I would say that most (if not all?) libraries have some sort of public methods / vars to use it, which would essentially be the "interface" ns

I think its only really worth it if you are building multiple applications out of a set of shared components though, it definitely adds a bit of overhead that is probably not worth it for a lot of projects