Clojurians Log v2

Yeah. .624 seems to be the breakpoint. (Spent the morning trying to fix my Cursive setup…)

I actually rewrote most of the tree stuff this morning, still working on it though

:dependents yes - that’s part of the lib map, :children no

@cfleming ah, I see where I broke it, will fix. I don't know who's updating the homebrew core tap, but it's just random versions now

@alexmiller Ok, I basically copied your make-tree function and fixed my copy in Cursive. As long as I can rely on the :dependents/`:children` bit coming back from resolve-deps that’s probably a better idea anyway, since I won’t have to fix anything if you change make-tree to do something different.

the bug was in the last refactoring of lib-paths

so basically in the guts of resolve-deps

you can't rely on :children - that's implementation detail leaking. :dependents you can rely on as that's part of the lib-map data structure and is spec'ed https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/specs.clj#L60-L64

Is dependents enough to build the tree without children?

depends what you're trying to do with it

make-tree is going to be moving and changing quite a bit - are you using that directly?

Basically, show the user a dependency tree in Cursive.

I was, but after working around this bug this morning I’m now using a fixed copy of the old version.

this whole thing with you depending on whatever arbitrary version the user happens to have is crazy talk man

That’s why I want data I can depend on in the resolve-deps results (or anywhere else, don’t care where I get it from) that I can use to build a tree to show the user.

the reason I'm rewriting make-tree is I suspect the same reason you're relying on that stuff - to better form the tree and the lib-map not being sufficient

Basically, until there is a defined API that gives me what I need I have no choice but to hack the guts.

Which is intrinsically tied to concrete versions.

well, depending on specific concrete versions is fine :) it's having no control over what you're using that seems like crazy talk

I can never control what the user has installed.

I can let them choose the version that they want to use, but I can’t mandate versions.

@cfleming What are you actually using this information for?

I guess I don't see why you can't use a specific version of tools.deps independent from whatever clj they have installed

Because when you introduce new stuff in deps, people aren’t going to like having to update Cursive to get it.

seems better than having it break every time I update clj

And as long as there’s a stable API, it shouldn’t matter.

there's not a stable API

that's the alpha part

Then it will break.

@seancorfield In this particular case, to show the user the deps tree in the IDE: https://cursive-ide.com/userguide/deps.html#viewing-your-project-dependencies

If the user finds a particular version of deps breaks with a particular version of Cursive, they can choose the version of deps they want to use within Cursive, or they can downgrade their CLI until either Cursive or deps gets fixed.

I'm continually impressed at the work you do with Cursive but at the same time it just reinforces why I like a simple editor and simple command line tools 🙂

ed will always be there for you.

🙂

You can pry Atom/Chlorine and the Clojure CLI from my cold, dead hands mate!

(although I've recently taken to using Reveal instead of REBL, just as an experiment with my workflow... but I'm missing several of the REBL features)

To be fair, I think you have a broken script until the CLI is fixed.

fixed in clj 1.10.1.645

which is uploading right now

looks fixed -- thanks @alexmiller

And my outdated deps script works again -- yay!

@cfleming I'll give you a heads up before I publish the tree stuff - still working on it.

Ok, thanks.

just as background, deps expansion does not actually ever build an explicit tree during expansion and in fact it's not a tree, it's really a graph.

the make-tree/print-tree stuff is kind of retroactively trying to build a tree from what's in the lib map, but that's really also not an explicit tree and does not contain sufficient path info to respect the exclusions the user originally stated

I've rebuilt the tree stuff to work from the trace (which is actually returned in the metadata on the lib map if it was requested), but it's surprisingly complicated to rebuild a tree that matches the user's original intent

I can believe that.

Mostly I’d just like a stable way to replicate what you show the user on the command line in Cursive.

yeah, and there will be a function somewhere that can work from the trace (which you can actually emit from clj with -Strace) to give you that tree data

I mean, I can actually show them a graph if required.

that's kind of the stuff I'm wrestling with - there are multiple things you might want to show

what most of the deps tools show is basically a tree with every lib listed once (even though it's really possibly a dep at many points)

but you in particular might really want the "full" tree - full expansions at every node (could still stop at cycles in a path)

and then for debugging you really want to know - what version was requested, what version was actually selected, and what libs were excluded at which different points

Yup, and then I could collapse duplicates to mirror what users are used to seeing in other tools, while still allowing them to expand them if required.

all of that info is in the version map included in the trace but it requires a fair amount of trawling

When you talk about the trace, do you mean something included in the new basis stuff?

no, pre-dates that actually

clj -Strace will dump a trace.edn file

Is that documented anywhere? It doesn’t seem to be in the reference doc.

no, I wasn't sure how stable it was going to be. I added that when I made tools.deps.graph so basically prior to my conj talk

but it hasn't actually changed since then I don't think and this tree work will add another "user" of it

Ok, looks like I could use that if the generation of it were available in t.d.a and I could call that.

it has been available in t.d.a since since last November in the return of resolve-deps

if you pass the :trace option, it will be included in the metadata of the lib map that's returned

that part is doc'ed at https://clojure.github.io/tools.deps.alpha/#clojure.tools.deps.alpha/resolve-deps

Ok. If that’ll be a more stable thing for me to use I’ll start using that.

no plans to change it ;)

What’s missing from the doc is descriptions of what’s actually in the trace log, or the runtime basis for that matter. Are they specced or something?

no, I wasn't quite ready to commit to them yet and haven't really caught up on that

the basis is doc'ed in calc-basis

https://clojure.github.io/tools.deps.alpha/#clojure.tools.deps.alpha/calc-basis

it is all a bit strewn around atm and specs are missing some of those

so, definitely some doc debt to pay back. my time is kind of split right now with joining nubank :)

Ok, when I get some time I’ll investigate switching to that, and falling back to what I do now if the metadata isn’t available. I’ll be interested to see your tree code when it’s done.

Anyone know of a docker image containing both leiningen and clojure? I’m migrating a project piece by piece and am using the lein-tools-deps plugin. Currently using jdk 8, as well, unsure how hard that dependency is though.

slightly off-topic but still ) In case if you are using github actions - https://github.com/DeLaGuardo/setup-clojure it can provision all three “main” clojure tools: leiningen, boot-clj and tools.deps

https://hub.docker.com/r/lambdaisland/clojure this image comes with all those tools as well

@pez FWIW I usually just install clojure in a Docker container myself

See any of my latest projects

For me this was on topic, because it is for CI I need it. (Using Circle-CI, but anyway.)

Installing Clojure and lein isn’t too difficult. This is an old snippet from a buildspec.yml for use with CodeBuild and CodePipeline. Adapting it to Docker should be relatively straightforward.

Yes, I went that path. (But installed clojure in a lein image.)

@pez CircleCI has lots of docker images to choose from https://circleci.com/docs/2.0/circleci-images/#clojure

Oh, it seems you mean Clojure CLI tools and not Clojure.... sorry.

Yeah. The lein image contains Clojure but not the tools.deps stuff.