Clojurians Log v2

Morning

¡¡måning¡¡

Good Morning!

👋

Morning

Anyone seem the photos of SF yesterday?

It's like a scene out of The Martian

i like the idea that the iphone photography software assumes its wrong, and rebalances the colours

mogge

Morning! is anyone here using deps.edn, and if so do you have a "lein-ancient" equivalent that is prefered?

@peterwestmacott yes we use it. You can use Depot or deps-ancient for that… See also: https://github.com/clojure/tools.deps.alpha/wiki/Tools

I use antq

depot is not actively maintained, deps-ancient is broken for the latest tools.deps and antq doesn't actually update your dependencies - am I missing something?

I think depot works despite being done.

Most tools won't touch your deps.edn to protect your comments and such.

Morn'

@peterwestmacott Depot has an update mode but I think tools modifying my project config is a Bad Idea(™). My main complaint with most of these outdated deps tools is that they don't follow the same semantics as the CLI / deps.edn because they try to read the EDN files directly instead of relying on t.d.a's semantics for finding and merging dependencies under aliases etc.

(in particular, we use CLJ_CONFIG at work to override the user-level deps with a repo-specific one, and then we have a deps.edn in each of our 30+ subprojects in the repo -- and we rely heavily on :override-deps in the "master" file, which those tools can't cope with)

we've gone with depot for now - it claims to leave your whitespace and comments alone

We used to use Depot at work. Up to 1.8.4 (where it used to follow the CLI / deps.edn semantics correctly). But the update code used different rules to the reading/reporting code, and then in 2.x they switched the reading/reporting code to use the same (incorrect) semantics as the update code. Argh!

I'm curious about "they don't follow the same semantics as the CLI / `deps.edn` " - what problems do you actually see in the real world as a result?

So I wrote my own, using a shell script that just runs clojure -X:deps tree against two sets of deps (the repo set and a synthetic set created from those).

As noted above: not respecting CLJ_CONFIG, not working properly with aliases, not following :local/root semantics. Lots of things that are avoided by leveraging t.d.a instead of just trying to read EDN files directly.

Reading the EDN only works in very simple setups.

thanks!

I suspect I'm more sensitive to that issue because of the setup we have at work: a monorepo with lots of subprojects, that depend on each other via :local/root, and nearly all of our dependencies are specified as {} for the version, which is supplied from a separate deps.edn alias (`:defaults`) via :override-deps.

It feels a bit like there's a world of things cobbled together (not in a derogatory sense) around deps.edn but as yet no Right Way(™) to do it all

I guess it is still alpha!

It will be interesting to see what tools.build offers.

I've talked with Alex a lot about that, in the context of JAR building and depstar.

is that a secret project?

or am I bad at search engines?

Alex has mentioned it on and off in some Inside Clojure blog posts and in the #tools-deps channel here.

It's stuff that's coming out of the work they do at Cognitect on Datomic and other projects. Beyond it having a JAR builder feature, not much has been discussed in any detail.