Clojurians Log v2

You can put it wherever you like of course

I know I can, I just don't want to miss out on anything I might have overlooked, hence the question 😅

Nope, that just seems to be where many people prefer it

Thanks for that info Alex

@souenzzo I seem to be driven towards something like that too, only that at this point I prefer keeping even build-only and dev-only stuff separate, with the former used both in CI and local dev, and the latter only in local dev. I ended up with the following aliases in a recent project:

{:aliases
 {:build ;; clojure -Srepro -T:build <clean|compile|...>
  {:extra-paths ["build"]
   :extra-deps  {,,,}
   :ns-default  build}

  :dev ;; development repl with build support: clojure -A:dev:test:build
  {:extra-paths ["dev"]}

  :test
  {:extra-paths ["test"]
   :extra-deps  {,,,}}}}

@imre Could you elaborate on this concern? > adding . as a path means everything in the repository ends up being on the classpath I mean, yes, technically it makes your entire project available but it's just one entry in the classpath so it's not like it massively expands the classpath itself, and any Clojure source in your repo won't be accidentally loadable because src/my/namespace.clj won't match if you require my.namespace, nor if you require src.my.namespace. Or, more likely in your case, components/my-thing/src/top_ns/my/namespace.clj 🙂

One reason - probably the more subjective one - is that I prefer my classpath clean these days -- try to only have stuff on it that I need. Another is that if I end up actually needing something from "src" (like a version.cljc that's used both by the app and the build script) then I prefer only having it on the classpath once.

In the polylith workspace I'm spending some time on I'm actually making build a poly project with its own base. It's going to be a more involved build pipeline and I expect some benefits from being able to share poly components between the build script and the deployables built using it.

It might be overkill but if I'm already in a poly workspace I don't see a reason not to try and use it to its full benefits. I will also want to unit test the build code itself which this approach makes rather easy

But then these last 2 are quite polylith-specific

Yeah, in a Polylith workspace, I can see the benefits of the build "script" being a Polylith project. Our :build alias includes a base and a couple of components so it might make sense to make it a project...

(our :build alias already includes Polylith itself as a dependency since we directly invoke some parts of the poly API in build.clj)

same here 😅