Hi! 1. Yes. We have several services defined as separate projects in our Polylith workspace. However, in our staging environment, we do not want to deploy them as individual services (due to saving some dollars, small startup 💸). 2. Yes. One project in our workspace used for the staging environment has a base that requires the entry points of all other bases to achieve the scenario I explained above. 3. No. Our bases are usually straightforward that don’t require complex testing needs. 4. No, it would break our current model and require us to duplicate code. 5. Yes. I thought that check was already there 😂. I don’t think it is a good idea to have circular dependencies. 6. clojure -M:poly 7. Yes, always in shell on my local machine. Only run commands without shell on CI.

We don’t calculate dependencies between bases at the moment and if you run the deps command, you will only see dependencies to interfaces and/or components (if a project is given with e.g. project:myproj ). I added two more question that you now can answer Furkan!

1. No. 2. No. 3. Yes. We have one base whose test setup depends on, essentially, being able to run another project's base app in-memory. 4. Yes. 5. Yes. 6. clojure -M:poly shell for general use in development; clojure -M:poly ... for CI and other commands. Our build.clj script runs clojure -M:poly ... as a subprocess for several things. 7. In development, yes.

@U1G0HH87L edited my comment above 👆

1. Yes, I have a project with minimal dependencies and one with all features and many dependencies. This requires two (slightly) different bases. 2. No, I do require the base with all feautures in development/user namespace to avoid duplication. 3. No 4. Yes, I think so. 5. Yes 6. clojure -M:poly 7. Yes, since it is faster. Without shell on CI. But sometimes I get classloader errors in the shell (after some time), so I’m also often running the test command (`clojure -M:poly test`) outside of the shell.

Thanks @U0FT7SRLP. Next time you get that classloader error, try to restart the shell and see if you still get the error. I wouldn’t be surprised if the error goes away, and that it is a state problem.

@U1G0HH87L Yeah It always goes away when I restart it I believe. But the error is sometimes hidden in a stacktrace, so to prevent me from searching for it, I tend to just call the script outside of the shell. I will try to observe my own behaviour next time it happens 😅

We should probably add this to the documentation that it’s not reliable running tests on a long living shell session.

@U0FT7SRLP Re: 7. and classloader errors -- that's part of why I created the external test runner: https://github.com/seancorfield/polylith-external-test-runner

(it also ensure all memory is freed up between test runs)

> We should probably add this to the documentation that it’s not reliable running tests on a long living shell session. Or link to my external test runner? 🙂

@U04V70XH6 Thanks, I'll give it a try! I believe it was a memory issue indeed

Good point @U04V70XH6. Do you have the same problem @U2BDZ9JG3 when running tests from a shell? Or maybe you don’t have long living shell sessions?

You know me, no, I haven’t seen such classloader errors and don’t keep things running too long 😂

You two guys seem to have two different ways of working! 😂

My poly shell runs for days, like my REPLs:grin:

1. No. 2. No. 3. No. 4. Yes, it wouldn't matter. I had an understanding that bases aren't meant to be dependent on one another (though they can) 5. Yes 6. a. poly. I have multiple repls when working with clojure, and one of it is always poly 7. yes. it is faster and can benefit from auto completion.

@U01TFN2113P Do you really mean you have a single projects deps.edn file that depends on 20+ bases? Or do you mean that you have a Polylith monorepo with over 20 bases?

Ah, I misread the question. In a single project there is usually one base.

I'm very curious about the use cases folks are posting where they have more than one base in a single project (build artifact, essentially). @U2BDZ9JG3’s is interesting: a single "mega-project" containing "everything" which I totally get -- but I'd be very concerned about deploying something to production that isn't exactly what was tested in staging. I don't quite understand @U0FT7SRLP’s use case -- it sounds like one-base-per-project but two closely-related bases that each have their own project?

@U04V70XH6 So far as I understand the Polylith project should collect all dependencies of your components, and the bases are where you put the glue code. Assuming I was correct here, please let me explain how this leads me to two bases. I’m working on a project that I want to publish as a big uberjar and (maybe) as a native (Graal) command line tool. The native part does not tolerate all the dependencies I use in the uberjar version so it’s a stripped down number of dependencies (through the project’s deps.edn), and therefore it also needs to glue things (slightly) different together in the base. Does this makes sense?

@U1G0HH87L Maybe also relevant to this discussion are my other sins: 1. Sometimes I cheat the Polylith restrictions by having inline requires. And this breaks the incremental testing idea, so I have to run all the tests to sure (for now). At first this was because I was migrating things from a different architecture, but now I still do it sometimes when I don’t know what interface I want to expose exactly. 2. 2. I created a basic babashka script that can enables to autotest a component on file changes with Kaocha. If this is interesting I can touch it up slightly for sharing (might be actually broken now)

Yes, but does that mean your projects have multiple bases in a single deps.edn file?

@U04V70XH6 Ah I think I misunderstood the question. No I don’t actually. I will correct my answer 😊 (I was confusing Polylith project with the outer project..)

Maybe @U1G0HH87L needs to edit his question to be clearer then? 🙂

(Btw, I have a similar confusion with bricks and components)

With the outer project, you mean the workspace/repository? @U0FT7SRLP

@U0FT7SRLP Regarding your two points: if you're cheating Polylith then... well... 🙂 and auto-testing on file changes has always seemed like a bad workflow to me -- and I've had bad experiences whenever I've tried a filewatcher approach 😕

Reword Q1 as Do you depend on more than one base in any of your projects/*/deps.edn files?

@U04V70XH6 Yeah I fully understand it’s not the way, just my confession here. Regarding, the autotesting, I see what you mean. It’s just in addition to repl testing, polylith testing etc

It's like folks who use tools.namespace.repl/refresh and I'm just like 👀 orly? 🙂

Haha no I’m actually using it differently. And I don’t dare to run my tests in that way anymore. The usecase is actually not more than iterating on one file

> Reword Q1 as Do you depend on more than one base in any of your projects/*/deps.edn files? @U04V70XH6 No so actually not. Sorry for the disappointment. No revealing usecase here 😞

To be fair, I’ve gotten less positive feedback too from some Pythonistas out there 😆 “… this opinionated layout is actively hurting project development and I am and will be very vocal that no one should ever follow it …” “… I have read it and thinking it is not very living architecture pattern. … Better to read book from Eric Evans about Domain Driven Design i think. … not very useful. …”

@U018VMC8T0W It would be great to reach out to find out in what scenarios it isn't working. The criticism is vague on details. :thinking_face:

These ones are first-reactions after only browsing the docs and reacting about words like “architecture” - a 🔥 topic. The ones actually tested it are 😍

Another thing that I try to find ways to explain is about breaking free from the very rooted idea of putting shared code into versioned libraries. Polylith does it differently and that has been a source of debate when I’ve introduced Polylith for Python devs. It is often a ⛰️ to explain that bricks != libraries.