Rewrite build to tools.deps?

[alexander-yakushev]

Given how Leiningen is showing its limits in a project like this, and that it cannot resolve git deps which Orchard uses a few, what's the consensus on using tools.deps based build setup? It can be done only for testing, keeping Leiningen for building/deploying, or for both at the same time.

[vemv]

Given how Leiningen is showing its limits in a project like this

(Please expand)

lein-git-down works perfectly, has never let me down over 5 years. We use it in clj-suitable.

Lein allows us to do eval (~), advanced profile merging, plugins, etc. If anything it's more capable than tools.deps - very good fit for our advanced needs.

[alexander-yakushev]

(Please expand)

I meant two things:

1. Not being able to run the test suite directly, having to resort to java call.
2. Some of the building logic has to exist in the Makefile.

I don't see advanced profile merging as a benefit – vice versa, it's a drawback that Leiningen arbitrarily enables profiles for different tasks, so that they later have to be disabled. tools.deps alias behavior is much more predictable in that regard.

Plugins are also mostly a crutch. All tools that Orchard uses as plugins have a tools.deps in-process API.

You can't do ~ inside tools.deps but you can write and run arbitrary scripts as separate files, something that Leiningen doesn't have.

I honestly thought that Leiningen feels more like a mismatch here (I remember Bozhidar complained about Leiningen limitations for cider-nrepl long ago and having to write Makefiles instead), but if not, then sure.

[bbatsov]

Let me ponder on this a bit. I’m fond of Lein in general, but there is no denying that tools.deps has taken the lead in the community and has certain advantages over Lein.

…

On Wed, May 1, 2024, at 3:11 PM, Oleksandr Yakushev wrote: > (Please expand) > I meant two things: 1. Not being able to run the test suite directly, having to resort to `java` call. 2. Some of the building logic has to exist in the Makefile. I don't see advanced profile merging as a benefit – vice versa, it's a drawback that Leiningen arbitrarily enables profiles for different tasks, so that they later have to be disabled. tools.deps alias behavior is much more predictable in that regard. Plugins are also mostly a crutch. All tools that Orchard uses as plugins have a tools.deps in-process API. You can't do `~` inside tools.deps but you can write and run arbitrary scripts as separate files, something that Leiningen doesn't have. I honestly thought that Leiningen feels more like a mismatch here (I remember Bozhidar complained about Leiningen limitations for cider-nrepl long ago and having to write Makefiles instead), but if not, then sure. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZLSXXG37NUJO73AIMY4DZADSZHAVCNFSM6AAAAABHB5NIE2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGQ2DEMRVGQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[vemv]

Not being able to run the test suite directly, having to resort to java call.

How is that a 'problem'? Where is it manifested? Have you tried running a test suite in tools.deps with enrich-classpath in it, for a fair comparison?

Some of the building logic has to exist in the Makefile.

Again, what's the problem there? What's even the difference vs. tools.deps and tools.build? You still get two phases.

---

Most of all, I'm concerned that we're not acting like problem solvers:

• Changes should respond to practical, objective, stated problems, not to opinion/philosophical ones
• The purpose of a build is not to be the neatest build ever, but to serve the people who regularly use it.

As the one person responsible for perhaps 99% of the latest couple hundred releases, honestly I don't feel that you aren't making my life any easier.

Analysing these concerns takes a non-trivial portion of the time and energies that I can possibly allocate to all things Cider.

As always, ultimately you can count with my good willingness (as shown in code reviews) but again, the sprit I try to share is to be problem-solvers, and to not break what's not broken (especially as all builds across our projects are actively maintained).

Cheers - V

[alexander-yakushev]

I’m fond of Lein in general

I, by mistake, have remembered it differently. If that is the case, then it doesn't make sense to do a transition, even though the community interest looks to be shifting away from Leiningen. Again, just gauging the sentiment.

[alexander-yakushev]

How is that a 'problem'? Where is it manifested?

To me, the problem is not having a good understanding what is being run, with which classpath, and with what implications. Maybe, it's a documentation issue, not a tooling issue. Maybe it's not a problem to you. But then, maybe, it is all partly related to why there isn't a line of contributors stacking.

What's even the difference vs. tools.deps and tools.build? You still get two phases.

There are benefits in having the build parts written in Clojure vs Bash/Make. Whether those are significant benefits is the point of the discussion. Notice this isn't a PR.

Analysing these concerns takes a non-trivial portion of the time and energies that I can possibly allocate to all things Cider.

Taking the time away from writing a fourth Java parser? Don't threaten me with good time, perhaps I'm doing god's work here.

ultimately you can count with my good willingness (as shown in code reviews)

Wow, I feel really blessed, so goodwill, much wow.

Whatever problem you have with your attitude, you might as well problem solve that first.

[bbatsov]

I’m fond of Lein in general

I guess the better term is "used to". 😁 I don't do much Clojure outside of CIDER and friends (and for historical reasons most projects use Lein and it mostly got the job done) and I never got to work extensively with tools.deps, so I'm not really familiar with its advantages.

I am on the road this week, but I'd be happy to discuss this further when I'm back in front of a computer. Typing on a phone has never been my strong suit.

[bbatsov]

Also - let's all try to cool off, as I see the conversation has gotten quite heated.

I think we're all on the same team and we can find solutions that will work for everyone together. Let's just stick to the topic at hand and civil and constructive discourse.