Clojurians Log v2

Here is my stab at it: https://github.com/borkdude/deps-infer

I think this can be improved in various ways (as documented in the README). Having an up to date (daily) index (of namespaces to lib coords) of clojars (and mvn central) available is one of the best improvements. Not hard, just has to be maintained somewhere.

I think such an index will also help detect namespace clashes in the entire clojure ecosystem which will be pretty useful

This tool can be used for e.g.:

- Making implicit deps explicit
- Checking which deps you are _not_ using by comparing the output with your existing `deps.edn`
- Porting a `lein` `project.clj` or `boot` `build.boot` to `deps.edn`
- Porting scripts (e.g. [babashka](<https://github.com/babashka/babashka>)
scripts) to a `deps.edn` project.
- Migrating from git deps to mvn deps
- Checking if there is a newer version available

I know where I'm posting this question and I'm not looking to start a flame war, but I've noticed that beginners tend to gravitate towards lein, not cli tools. 1. Is there a reason for that? 2. I suppose that part of the reason could be due to outdated tutorials on the web (lein was obviously more prevalent in the past). However, given that tools.deps is endorsed by nubank/cognitect, comes with clojure and is used by an increasing number of libraries, would you ever recommend lein over cli tools for new projects in 2021? If yes, why? edit: Apologies if this comes up too often 🙂

Probably UX is part of the equation: lein comes with a test runner, uberjar, etc, built-in

tools.deps doesn't try hard to provide a full tool for most needs: you have to assemble it yourself

there is a project in development called tools.build which might perhaps make this more beginner friendly, but this remains to be seen

There was a thread on Reddit (I believe) recently about this, if you want to read comments from the community. I like both tools for what they are. Tools.deps / Clojure CLI allows you to only use what you need, which is generally better for startup, etc.

Ah, good points, thanks @borkdude. Are you referring to this thread? https://reddit.com/r/Clojure/comments/jailzq/aleksandar_simic_from_lein_to_deps_and_back_lndclj/

No, it was a different one

@pavlos It was related to this blog post: https://quanttype.net/posts/2021-01-14-clojure-project-management-tool-of-my-dreams.html

Here is the Reddit thread: https://www.reddit.com/r/Clojure/comments/l3a2iz/clojure_project_automation_tool_of_my_dreams/

definitely more to come... from the world of tools.deps :)

deps-infer + add-lib would be an absolute dream

we've actually spent some time on this a couple times, but actually going further with integrating it into core

still trying to figure out where to draw the boundaries

we'd love to give you a ton of power at the repl and maybe in ad hoc scripting, but not encourage you to make a mess of your actual programs :)

we are working on some stuff right now that is taking another step or two in this direction

@jjttjj you can use deps-infer today :) It actually works quite well, I've solved a couple of small issues already

And I'm co-ordinating now with @tcrawley to fetch deps info from clojars 😍

The rewrite-edn lib was referenced here a couple of days ago and I thought I'd make a video on it: https://youtu.be/bPoe2N7J5yg

I did my own project workflow for tools.deps which has basic Leiningen functionality. https://github.com/redstarssystems/rssyslib

That's cool. Another attempt was done by @pyr as a joker script which I ported to babashka here: https://gist.github.com/borkdude/c34e8e44eb5b4a6ca735bf8a86ff64fa (original you can see via the forked link) This can even become its own GraalVM compiled standalone binary perhaps :)

But I guess a template is more flexible because you can tweak it later and won't require others to install the tool

In case, any folks aren't in #news-and-articles

@seancorfield So you basically have one top-level project to rule them all. But this will be forbidden in the future, unless I have misunderstood the warning:

worldsingles/worldsingles {:local/root "../worldsingles"}

I believe the warning is for outside paths, not for local roots

ah, you are correct sir

So why did we have to discuss this for 2 years before this solution emerged? It makes sense to me at first glance ;)

We have other scripts and Makefiles etc within the subprojects, so being in the subproject is a convenience maybe

But it's good to have alternatives. Thanks for the write-up Sean!

@borkdude I think @hiredman had the same response when he read over a draft of that article last night 🙂

I wonder how one top-level project solves the local/root caching issues you were seeing with the scripting approach. I've seen this problem in "normal" usages of local/root as well

I think I just kept holding out, hoping that the CLI would magically sprout a "fourth" deps.edn file in there... but I've given up on that now 🙂

Yeah, we're still at the mercy of :local/root transitive deps but it's much less of a problem now that we're not trying to auto-generate the deps.edn files: and now we only have a single .cpcache folder to worry about instead of one in every subproject, which means -Sforce should be sufficient in all cases now.

Ah, transitive local/roots, yeah, that we don't have yet

We only have direct ones for now

But this might change...

I still have a couple of tickets at work around cleaning up the last few vestiges of the "big shift" we just did last week to arrive at this new setup.

What I like about the scripting approach is that it doesn't rely on any features that I don't use often, just a simple "what you see is what you get" deps.edn

But it's good to know that this works in case the scripting approach has clear negatives

Of course, the CLI / t.d.a may change again in the future and necessitate yet another (big) shift but I get the sense that we're much closer to the core team's thinking about how deps.edn should be used now than we were in either of our previous incarnations.