One thing I will say is that clojure -M:poly is pretty slow to start up. I've been thinking about AOT-compiling this (once) into each repo to make tool startup faster but haven't quite got around to figuring out the mechanics of it in an ergonomic way.

Similarly, I think the initial "bootstrap" command is way overly complex, given that creating new projects is something beginners do a lot but experienced devs do very rarely.

Good point.

I think that having a good Polylith project template for deps-new would be a good approach. I have one for clj-new -- https://github.com/seancorfield/clj-new/#the-polylith-template -- but I'm trying to retire that and encourage folks to switch to deps-new.

Then setup becomes:

# do this just once:
clojure -Ttools install-latest :lib io.github.seancorfield/deps-new :as new
# then create new poly repos:
clojure -Tnew polylith :name my.new/repo

My assumptions in the clj-new polylith template are quite opinionated -- it creates a workspace with a base, a component, and a project rather than just a sparse workspace -- so I'd really like the deps-new polylith template to be more in keeping with what clojure -M:poly create workspace name:whatever top-ns:some.thing creates.

A problem I see with this is to introduce one more "tool" to create a workspace. It's not a big issue, but having only one way is simpler. I think keeping the installation instruction pretty much as it is today and then adding the bootstrap option is maybe the way to go.

A way to experiment with creating workspaces would also be to install it as a Clojure CLI Tool with clojure -Ttools install io.github.polyfy/polylith '{:git/tag "v0.2.18" :deps/root "projects/poly"}' :as poly and then they can use clojure -Tpoly create workspace name:whatever top-ns:some.thing.

clojure -Ttools install-latest :lib io.github.polyfy/polylith :as poly would be better -- but you lose the :deps/root config 😞

And also, the poly "tool" has to use the EDN arguments so it isn't create workspace etc.

Besides, if you install deps-new :as new you get to create all sorts of things -- if it gets a polylith template project...

Yes, you are right. But they can start a shell with clojure -Tpoly shell first, and then create a workspace from there (then they also get autocomplete when doing that).

My dot-clojure repo has poly as an installed tool BTW (although I probably need to update it).

https://github.com/seancorfield/dot-clojure/blob/develop/tools/poly.edn

I still think skipping the installation step initially, feels like a good idea, as it will get people started more quickly. We can tell the user to install the poly tool as a Clojure CLI Tool, and use the -T syntax to start a shell to create the initial workspace, and then use -T or -M when going forward. If they execute commands outside of a shell and feel that is slow, then they can install the stand-alone tool.

I will admit that I like the shell a lot 🙂

This is all very interesting info, thanks! @U1G0HH87L and I have decided not to try to solve all the issues we discover while reviewing the docs. We can raise git issues as needed. This one, to me, seems like a great candidate for a decision matrix.

Yes, let's wait with this.

Let's postpone this and create a decision matrix or similar in the future.

poly relies on the Clojure CLI and tools.deps so it doesn't overlap with Bazel at all.

You can definitely have a polyglot repo, but the poly tool isn't going to know how to deal with the non-Clojure parts of your repo. What other languages are you using?

Frontend part is svelte/JS. But really, it could be anything that will be stored in monorepo. Poly tool doesn’t help with building at all, so there might be some need to trigger builds for projects when specific component used there changes. I still haven’t decided if we’ll have one or multiple Polylith workspaces within the monorepo.