Clojurians Log v2
boot
At work, we started with Leiningen back in 2011, switched to Boot in 2015 because we needed more flexibility, and then switched completely to the Clojure CLI / deps.edn and associated tooling in 2018. I don't really advise trying to mix tooling (having tried to do it!).
It would be nice, IMO, if both Leiningen and Boot were refactored to build on top of tools.deps so they could use deps.edn directly and have their version resolution match the Clojure CLI, as well as have support for git deps and local deps. I doubt that will happen tho' (since even changing version resolution would probably be a breaking change for both lein and boot).
@seancorfield since taking over boot we are now working to achieve this goal of aligning with the deps.edn and not competing with other tool sets
This will require significant redesign of boot, however progress has already been made, boot uses a new shim (bootstrap) which has the potential for platform native images, a new v3 fileset is underway, once the fileset is a bit more complete we will start on rewriting the internals for boot.aether
Things we could use community help on - pods, tasks, cli apps, client/server architecture
@flyboarder Interesting... I didn't realize you planned to move Boot so far from where it is.
Are you planning to leverage tools.deps instead of Boot's current dependency resolution machinery?
I wonder how much of the existing tools.deps / deps.edn tooling it would end up duplicating tho' -- given "not competing with other tool sets"?
Just as a data point, what really forced us off Boot at World Singles Networks was a combination of two big problems with Boot's architecture: the fileset became an unmanageable overhead and pods had so many edge cases that we kept tripping over. In the end, both things felt like abstraction for its own sake and we decided that we weren't getting enough benefit from either to outweigh all the costs we were incurring. We really like the simplicity of deps.edn/`tools.deps` and it's been much easier to build custom tooling on top of that, rather than using Boot (which was, for years, certainly much easier than building on top of Leiningen!).
About the only thing we "miss" is a task pipeline, a la Boot, and we ended up writing a very small shell script for that (so we get the process isolation of pods but we have to bear the "weight" of starting a new JVM process... but most of our pipelines are short so it's not much of an overhead really).
@seancorfield yes I intend to leverage tools.deps, and replace the current pomegranate solution
as well as replace pod isolation with a pure clojure implementation
“not competing with other tool sets” - in my mind means creating complementary tools that enhance the ecosystem instead of segregating it.
> I wonder how much of the existing tools.deps / deps.edn tooling it would end up duplicating tho' -- given "not competing with other tool sets"?
@seancorfield I feel like the opposite. With the rise of tools.deps there are now many new tools that have subsets of the functionality of Boot, but without the test of time. So to me investing in Boot and the integration of tools.deps is getting the best of both. But this is from the point of the user and I'm not an expert on the internals of Boot. I'm happy to hear @flyboarder thinks this could become a reality.
(@flyboarder i'm testing with opencollective, hope to raise more than $5 dollars later)
> Things we could use community help on - pods, tasks, cli apps, client/server architecture @flyboarder i'm still interested in contributing to the client/server architecture idea. i'm not sure how much you've thought about it, but do you have an idea of where i might start? are there changes needed server-side?