> they get out of date very quickly True, but only for tech that changes quickly, and if you hard-code stuff that changes quickly, like versions and installation instructions. > they have opinions that you don’t share I only read the section about Poetry in that article, but seems like the author justifies his opinion, backs it by links. I think it's a good thing, to have an explicitly justified opinion. > they overwhelm you with things you don’t need or want > they induce anxiety Without such an article, the feeling of anxiety and of being overwhelmed would be even stronger, no? After all, there are many more alternatives to Poetry than the author mentioned. > they are a red flag for a given tech to be bloated/fractured But this is not a downside of the article itself.

Fully agree on all other points.

As counterpoint, I haven’t worked with modern Clojure for a few years now and I have no idea (to dramatize a bit, admittedly) where to start with deps.edn in such way that I’d have feature parity with Leiningen. Seeing some of the files written by people out there don’t seem to structurally match well; to compare to previous experience, most look like Ant scripts or maybe package.json for npm, neither of those being even close to what I feel is robust. The official documentation at https://clojure.org/guides/deps_and_cli doesn’t even tell me how to package things! With this in mind, the article above about python is perfect - yes, it could be boiled down to “install pyenv and poetry”, but it also explains the connections around the tools and the sort of intermediate questions people tend to have; not everything should or even can be condensed. There’s also another benefit of writing a how to X for dummies kind of documentation - it really exposes what the actual hurdle of getting started is, if you can’t write a short and complete guide about whatever you’re trying to explain, you might have an implicitly complex and hard to grok system… 🙂

I was exaggerating in my criticism and I certainly don’t want to bash the article. It seems very well made, and I‘m sure it is useful. Good points.

Lets all assume we all suffer from some combination of summer heat, non-native language communication issues and being in general hurry or in middle of other things… 🙂 That is, lets be kind and assume baseness even though we might seem polarized.

@U8SFC8HLP In the deps.edn world, you don't really need to "package" anything -- it works with source libs, direct from GitHub if you want (and that area has been improved substantially in the latest prerelease of the CLI).

@U04V70XH6 That doesn't answer what I then put in my Docker container, how I design my CI/CD pipelines efficiently, or how I audit the libs etc...and this is the metaproblem here 🙂

tools.deps does not have feature parity with Lein. It only manages dependencies and launching Clojure programs. tools.deps + the new tools.build now is starting to have more feature parity, as well as some new ones like source libs.

I think this is the biggest confusion, because people are used to the dependency manager being coupled with the build tool from other languages its often like that, Lein is like that, so its a bit of a mental model change (a great one)

People tend to forget that Boot didn't have a lot of stuff "out of the box" that Leiningen had: no built-in test runner, no way to create new projects from templates, and a bunch of other stuff was "missing" and needed to be provided by libraries.

Ah, lol, to be fair, I just assumed I never used boot 😛 Fixed it

In many ways, lein's "easy" monolith of tasks has done us quite a disservice. If it had inherently required plugins for several things that were bundled, our mental model of "building" stuff in Clojure would more closely match the "compose simple things" mindset that we use everywhere else 🙂

It's kind of interesting, even to compare depstar with how tools.build is organized. The latter is a bunch of very small, very specific tasks that you have to combine, even to build a library JAR (let alone an uberjar with AOT etc) -- the former has two "easy" tasks for those two types of JARs.

Compose simple things is good when you'll need to recombine them in different ways to accomplish different things. I think for builds, 99% of the time, you want the same combination. Lein has the issue that when you want something different you are stuck and need to write a complex plugin. But I think we will probably see some form of pre-combined tools.build show up as well, if not as another lib on top, at least as a copy/paste of templates and all that with predefined tasks.

boot’s death had a lot to do with the composability; builds should never be omakase this-is-what-I-think-is-best custom setups in every single project, and providing too much composability and reordering and whatnot is just a way to ensure there never will be actual pragmatic ecosystem where people can focus on what really matters, which only rarely is something else than actually solving a specific business problem. This is also why I still advocate for Maven on Java side, even with all the warts, both real and perceived. It’s Build Lifecycle as a specification is close to having the same kind of robustness as Ring spec, and on high level at least the ideas behind all parts of Maven are sound. Of course making your own Mojos is terrible, been there, done that… 🙂 but the point stands, the base is solid.

But this is getting quite far from original topic, so here’s my last two cents for at least that: I’ve been recently advocating for everyone to adapt https://documentation.divio.com/, especially focusing on the topright quadrant first as that provides the entry point to whatever it is that you’re documenting.

Ya, that be great, I remember technomancy mentioning that it was not so easy, because a lot of lein is tightly coupled to that stuff, but it would still be great in my opinion

This would work for many projects, but not all. I’ve worked with projects that called functions and/or evaluated macros in project.clj (personally, I hate this)

Wait 'til you find out about boot 😉

I've used this trick to update the version in project.clj automatically based on the contents of a file. But I moved away from this in favor of a templating + script approach

yeah. they can still stay on v2. or put stuff in a file. but that stuff is usually targeted around release stuff (not always). But the vast majority of lein projects don't need this and if they switched then deps could target them as git deps. But i think borkdude is right, if the deps were readable rather than executable it would be a big win

Leiningen is literally just a macro, I doubt this change would ever surface but feel free to file an issue/suggestion to Leiningen's github :)

inline eval is a killer feature, you can e.g. develop custom middleware without ever packaging it into a .jar which is awesome for iterating and sharing that work with others So, would Lein w/o eval be even a Lein? at that point one could as well use deps.edn and one of the many migration scripts

Well, even Alex in his recent talk said that builds are programs. But there is also something to having some static data like deps.edn available for inspection by tools, which the build program can then use.

A clear separation has advantages.

I'm not against project.edn, I'm against the idea of discarding powerful features

my lein setup reads nearly arbitrary deps.edn files and always works so I have everything: data + eval

yes https://github.com/gfredericks/how-to-ns