Clojurians Log v2

Right. I’ll wait with merging. 😃 I left some comments for when you return to the PR.

> Wanna have a go at it, @arthurfucher? @pez I would be happy to contribute, but I didn't get what will be the solution 😅 Also, if you agree, may I send a PR to update the docs (https://calva.io/debugger/#loading-the-file-and-eval-on-save)?

Yes, docs fixes are super welcome.

@arthurfucher I think the solution is: 1. Create a Calva command that fetches the latest versions and stores them in extension global storage. ◦ @seancorfield’s command line there, involving clojure -X:deps find-versions :lib $lib, but using node to shell out (there is prior art) ◦ falls back on something hardcoded in Calva (maybe there are lein people who do not have clojure?) 2. We also run this version fetching as part of Calva start 3. The current settings are retrofitted (same names) to override whatever is in extension global storage 4. Jack-in uses the settings first, otherwise global storage, otherwise hardcoded versions The end result would be that anyone who today uses Calva defaults, will keep using them (even if they now will mean latest shiny nrepl stuff). And that anyone that has configured their own versions, will continue to use those. We can include the current versions in the changelog so that it is easy for someone who’s not ready to use latest to go back to what we have today. Does this make sense? Also remember that in Calva dev, it starts with an issue stating the problem. 😃

I will be available for any help you may need. There is EDN parsing going on in some places in the code base (for getting the versions out of the find-versions command).

PR updating doc: https://github.com/BetterThanTomorrow/calva/pull/2958

Thanks @pez, makes sense! I'll try to tackle this... if I need any help, I'll let you know. Created the https://github.com/BetterThanTomorrow/calva/issues/2959, also added the proposed solution there to be easier.

References: • https://github.com/clojure-emacs/cider-nrepl/releases/tag/v0.58.0 • https://clojurians.slack.com/archives/C04CAKAGADU/p1757684821897969 • https://clojurians.slack.com/archives/C04CAKAGADU/p1758664348020789

Calva settings:

I currently have:

"calva.jackInDependencyVersions": {
      "nrepl": "1.5.0",
      "cider-nrepl": "0.58.0",
      "cider/piggieback": "0.6.0"
    },

Yeah, I've updated it manually here in my settings, but I think that would be good to have the default updated also.

Yeah, it always lags behind a bit...

Maybe we should do like we do with clojure-lsp and default to the latest versions, and allow pinning by specifying a version?

You mean "RELEASE" even tho' that's deprecated? 🙂

Yeah, we use latest with clojure-lsp 😃

A bit like add-libs does too. It just defaults to latest if no version is specified.

Wanna have a go at it, @arthurfucher?

RELEASE and LATEST mean different things tho'. The latter includes SNAPSHOT builds which, maybe, we wouldn't want?

(and the caveat that both of those kinda "break" the .cpcache algo for refreshing deps since they don't change when the version changes)

With clojure-lsp we use latest and nighly. Just because that’s what clojure-lsp uses. The name is not so important, the behaviour is.

Right. But the jack-in dep versions end up being passed to the Clojure CLI, which is why I made this point.

So, by not specifying a version we go for latest.

You can't omit the version in a CLI invocation tho'

We can figure out what the latest versions are and pass those?

How? Running clojure -X:deps find-versions ... and parsing the output for each of those libs?

I haven’t thought about how. 😃

Heh, I have...

Is what you floated there feasible?

Since you have three deps, I would not recommend running the CLI for each of those to find the latest version, just to figure out what to pass to the jack-in command. That was a sarcastic/rhetorical question. You could just pass RELEASE in the jack-in CLI as the :mvn/version and it would "work", modulo the caching issue.

I think using RELEASE would mean it would only check for a new version once a day but I'd probably have to confirm that with Alex...

I could ask in #tools-deps...

Ah, but that’s fine. If someone needs a new version quicker than that, they can clear the cache, I guess?

Yeah, or override the jack-in deps settings.

I just wanted to point out that it won't necessarily pick up new releases "immediately"...

Per Alex, it seems like this case would only cause new versions of the jack-in deps to be checked if the project deps were updated. If you don't update deps.edn, the cached basis etc would never change, and the deps will never be requested -- so jack-in deps would go stale.

Perhaps the way to go with this is to include that clojure -X:deps find-versions ... stuff in Calva's CI so that each new release of Calva always has the latest jack-in deps at that point in time?

Given how often you release new versions, that seems like a good compromise...

It still requires a release to update these. I would like to avoid that, if we can. Calva could have a command for updating the versions. This command runs on start of Calva, and can also be run at will. Jack-in uses whatever versions have been discovered latest.

(!1999)-> for lib in nrepl/nrepl cider/cider-nrepl cider/piggieback; do echo -n "$lib " && clojure -X:deps find-versions :lib $lib :
n 1 2> /dev/null; done
nrepl/nrepl {:mvn/version "1.5.1"}
cider/cider-nrepl {:mvn/version "0.58.0"}
cider/piggieback {:mvn/version "0.6.1"}

marked the PR as ready for review 😇 • addressed your comments • add an integration test (let me know what do you think about the test itself) • Updated docs

Thanks! Taking a look and taking it for a spin!

Works like a charm! At least the happy path.

I've created a draft PR to get feedback 😇 https://github.com/BetterThanTomorrow/calva/pull/2960

So sweet! I’ll look a bit closer tomorrow, and probably merge. Things look very tidy!

No need to hurry up, enjoy the weekend

Merging PRs like this is my idea of a sweet weekend. 😃

Ohh about merging, I think that it still require some changes.. Like default versions, docs.. And probably I will not have much time to take a look this weekend