Fork me on GitHub

This article is fantastic


A similar guide for deps.edn, depstar, tools, clj-kondo, calva/cursive, etc would be :thumbsup:


will you write one? 😁


I disagree somewhat. Here’s my experience with these types of tutorials: they get out of date very quickly, they have opinions that you don’t share, they overwhelm you with things you don’t need or want, they are a red flag for a given tech to be bloated/fractured, they induce anxiety. I skimmed over the tutorial and it is nicely written, clear and gives rationales at every decision (although some seem to be half baked). I don’t critize the author, I think it is well intended. But for these kind of guides to be more robust (over time), they have to be shorter, more general and refer as much as possible to external (official) sources as possible. Also specifically here, I would also make them more optional/modular: „here’s a list of tools that are useful because they solve x/y/z problem“ instead of „here is what you should install because of opionion a/b/c“. Clojure in particular is often at least a second language (unlike python), so a Clojure beginner comes in with a set of questions, curiosity and maybe some doubt. One of the driving questions might be „is it really as simple as this guy on YouTube said?“. If they get hit with a large list of installation recommendations they might get demotivated. But if they face a nice set of optionally useful tools, in a quickly skimmable fashion, they might find just what they need.

👏 10

> 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 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.

😁 4

@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 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 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 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, especially focusing on the topright quadrant first as that provides the entry point to whatever it is that you’re documenting.

👍 3

deps.edn will bring a brighter tomorrow. Program=Source, cut out the middleman, no fractal-shaped declarative configs to override the overrides of the exceptions to the built-in rules. But I giggle at the thought of a beginner guide to deps.edn. A beginner wants to do what is necessary today, focus on Clojure not the tool. That means: setup without sudo, start a REPL, run unit tests, make a jar, and not worry about what version of the tool they have today, or ever update it. That's Leiningen in a nutshell. It's been years since I wondered which version of Leiningen the instructions referred to. The deps.edn way has been in progress for years - and is apparently useful, on a treadmill basis - but it's not doing beginners a favor to throw them into that vortex just yet. To draw an analogy, I support the space agency but I do not tell people to pack their bags for Mars.

👍 4
👽 4

lein could consider adopting tools.deps.alpha as the deps resolver, I would be in favor of that, so we could also start using git deps / prep phase, etc. from lein

💯 2

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

Joshua Suskalo13:07:39

And have consistent transient dependency resolution so that transitive dependencies will be the same between lein and the cli


that would be a result of adopting deps.alpha

Joshua Suskalo13:07:24

Yup, just an important one to note if people are unfamiliar


yeah. would be cool if there was a lein v3 that switched project.clj to project.edn


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)

👍 4

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

👍 2

or just deps.edn with lein specific config in :org.leiningen/project {....}


but this would perhaps be a too big of a jump from existing lein projects. the first migration step should really be tools.deps.alpha resolver + git lib support if you ask me


It might be easier to create a tool.lein that is just a Lein like declarative macro which translates things into a under the hood


Are there any libs out there that can sort :requires and :imports lexicographically (and, as a bonus, grouping them first by whether they are core clojure libs, 3rd party libs, or project-internal nses)? something like this but for clojure

👍 2

@lgessler clojure-lsp as a command line application can do this I think... right @ericdallo?


it even sorts the :refer entries


we have a 60 or so line function at work that does this to a mostly acceptable degree


Yes, it but ATM it sorts lexicographically only


it can even remove unused import/requires if you are interested


oh, the other sorting, just don't do that

☝️ 6

I've worked on projects where they sorted like that it, and it is just way easier for basically all the benefit to just sort purely lexicographically


our code at work uses doseq over file-seq to find files that end with .clj, then reads clojure forms out of the file using the clojure reader looking for ns forms, then when it finds one it does the sorting using walk/postwalk of all things, then grabs the current line from the rdr that you where reading forms out of as the line after the ns form, then creates a new reader to readlines out of, copies those lines to a new file, but when it gets to a line that matches the :line metadata of the ns form, it writes the pretty printed sorted ns form, and skips lines until it reaches the end of ns form line, and continues copying, then copies the temp file over the original file


there are some newer reader features that might make this kind of thing easier, I forget the details but if you ask nicely the reader will attach the read string as metadata on the form it returns


rewrite-clj is a tool that makes this really really easy


yes, but can it do it simply


that too yes


ty all, looks like i got options!


Was just about to ask what was the name of that library that rewrites clj!


If you use Emacs and have clj-refactor you can do: cljr-clean-ns see:


It does more than just sort though, it also like standardizes everything


And if you just want to sort and use Emacs with clojure-mode, you can do: clojure-sort-ns, no REPL necessary