Clojurians Log v2

Good morning! I think I would go for option c if that can help out with the dependencies (I’m not sure what changes you want do to the new project though). And yes, you are free to create projects that don’t include bases. The polylith codebase contains the api project itself that was an experiment where I AOT compiled a library that I used from Kotlin to test if I could reuse the polyfunctionality from another language (it’s not publicly exposed at the moment, but I have an idea to expose two variants, one “normal” clj version and one AOT compiled). So building libraries is one use case, but your use case seems perfectly fine for me.

Something I think might be helpful for managing the :dev alias in deps.edn: a subcommand in poly that looks through all the bases and components and warns you about any missing src and/or resources paths in :dev and any missing test paths in :test — and in addition gathers up the full set of :deps from bases/`components` and warns about any missing from the :dev alias (and perhaps anything from bricks’ :test aliases that should be under the main :test alias in the workspace-level deps.edn file?).

Good idea!

I guess the sync command that we discussed earlier could help out with that too (for people that want to use it).