This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-24
Channels
- # aleph (19)
- # announcements (59)
- # asami (34)
- # aws (1)
- # babashka (17)
- # beginners (174)
- # bitcoin (11)
- # calva (16)
- # chlorine-clover (5)
- # cider (5)
- # clj-kondo (14)
- # cljsrn (13)
- # clojars (25)
- # clojure (124)
- # clojure-australia (1)
- # clojure-europe (48)
- # clojure-nl (4)
- # clojure-spec (1)
- # clojure-uk (40)
- # conjure (6)
- # core-async (25)
- # cursive (30)
- # data-oriented-programming (3)
- # datomic (14)
- # depstar (14)
- # emacs (3)
- # graalvm (27)
- # helix (1)
- # honeysql (25)
- # hoplon (3)
- # jobs-discuss (6)
- # kaocha (3)
- # lsp (109)
- # lumo (1)
- # malli (5)
- # meander (21)
- # music (1)
- # pathom (1)
- # re-frame (4)
- # reitit (1)
- # remote-jobs (1)
- # reveal (11)
- # rewrite-clj (3)
- # shadow-cljs (42)
- # spacemacs (15)
- # sql (13)
- # startup-in-a-month (4)
- # tools-deps (45)
- # vim (16)
- # xtdb (23)
- # yada (1)
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]()
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/
@UEQPKG7HQ 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/
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 @U06V097TP 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
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
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
@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"}
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
@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.
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.