Clojurians Log v2

Hey Sean, you mentioned there's been a previous discussion about this. Where's that located?

@lambeauxworks which "this" are you referring to?

Your first response to Phill. You mentioned another discussion.

> just to check: have you read the whole of the previous discussion about this?

Heh, three weeks ago...

Just context hunting! :)

This feature was discussed before it was implemented, hence my question to Phill. Pros and cons. You'd have to search back in this channel. I'm on my phone.

Gotcha.

Maybe this https://clojurians.slack.com/archives/CBE668G4R/p1760987101382249?thread_ts=1760987101.382249&cid=CBE668G4R

Using an uncontrolled latest version by default (for Jack-in libraries, the LSP server, cljfmt, or anything else) increases most users' exposure to a supply-chain attack. Allowing the user to "pin" a version of each individual part is a robust alternative, but it saddles not the energized Calva groupies but rather the innocent masses with the inconvenience of researching which versions work together, and the burden, whenever a question arises, of not knowing whether it might stem from unusual version choices or something else. The inevitable catastrophe will strike people who did not know they had "asked for" it. I think the risk merits an opt-in. I would like to suggest a middle ground, a "use versions fixed by Calva" (default), vs "use versions I specify" of which each may be a number or "latest"? Would an issue be welcome, and would those be the choices?

@phill just to check: have you read the whole of the previous discussion about this?

It’s unclear to me how this increased the supply-chain attack exposure. Can you elaborate on that particular one, @phill? As for any inconvenience in finding a working trio. Calva ships defaults, and adding the config will start with these defaults.

I am finding this a busy time of year... If someone beats me to https://github.com/BetterThanTomorrow/calva/issues/2969 or portions of it, their heroism will be appreciated!

To start with, I made an issue: https://github.com/BetterThanTomorrow/calva/issues/2969

Friends do not let friends start with PRs without there first being an issue. 😃

Would it perhaps be better for the settings that allow you to override Calva's default jack-in dep versions to be a separate configuration file, rather than combined into settings? I know that would mean it wouldn't auto-sync to other machines (assuming users have sync enabled and use multiple machines!), but then it would be more visible in a project? customREPLCommandSnippets is already handled that way, yes?

Having the versions in settings just feels a bit buried and easy to miss/forget, since you can't actually set them in settings directly, you have to edit the JSON. I think perhaps I don't like any settings that you have to edit the JSON for, instead of being directly exposed in the UI...

For the repl snippets there are mainly two reasons to support dual config buckets: 1. libraries can provide these 2. it’s Clojure code I just learnt that we can enable the settings UI for this config:

"calva.jackInDependencyVersions": {
  "type": "object",
  "description": "...",
  "additionalProperties": false,  // <-- This enables Settings UI rendering
  "properties": {
    // ...existing properties
  },
  "default": {
    // ...existing defaults
  }
}

That's already a huge improvement, IMO!

Can Calva surface internal (updated) defaults in the settings UI? In other words, user sets those versions to override Calva, then updates Calva -- can the settings UI show that Calva's new defaults after the update are different to what the user has explicitly set?

Or perhaps a warning at startup, showing both Calva's defaults and the user's settings?

The Settings UI shows when a config has non-defaults. Also offers to reset it. The UI also shows if the setting has non-defaults in some other scope then the one you currently look at.

We could print the messages about versions in the REPL Output destination in addition to printing it in the Calva says output channel.

Oh, that's nice. I didn't realize it would add all that information. Yeah, I think exposing those properties and adding a message to the REPL Output at jack-in would cover it (IMO).

Oops, that thread took quite a turn! I lost track before it shifted to discussion of auto-updating tools upon every jack-in. Anyway, I just noticed an eloquent opinion (on a question unrelated to Calva) from @p-himik > If you want to always use the latest version of org.clojure/data.json - just don't. Dependencies are specified with a fixed version for a reason. > There's a keyword, RELEASE, ...that would make clj occasionally check for the most recent version.... But that should be used only for development tools, and even there it's usually a questionable practice. https://clojurians.slack.com/archives/C03S1KBA2/p1764153529030889?thread_ts=1764147772.350729&cid=C03S1KBA2

Alright @phill, I have let this stew a while now and I am coming over to your side. I’m now leaning towards that removing the “always use latest”, and not even have a setting for enabling it. We could use the facilities for fetching latest to help users to quickly configure latest dependencies as their pinned ones on demand, instead. You offered to cook a PR. Does that offer still stand? 😃

A colleague had an issue with after updating Calva, he was not able to start the REPL , and we discovered that the project that he was using has an old version of cider/orchard as dependency (`"0.34.1"`). When trying to run the REPL it throws an error:

ERROR: Unhandled REPL handler exception processing message {:op eval, :code *ns*, :id 1}

> • They can have bugs, and Calva users will get them first without previous testing The #nrepl team is pretty good at keeping the quality up on their releases. I don’t worry much about this as long as users can easily use fixed versions, which they can. Same with the almost 0 breaking changes risk. Your colleague’s situation is more of a worry to me. That would have happened if we had manually updated the hardcoded default dependencies too, so is not really due to the auto-use of latest. What we should consider is if Calva can can help with suggesting courses of action when Jack-in fails. Like tell the user to check for nrepl dependency issues (and choose between pinning Calva’s dependencies or removing/updating the conflicting project config.) Maybe @seancorfield knows how we could create a dependency report/check for the relevant dependencies that could help users when they run into things like this?

I think CIDER used to warn when using a combo of CIDER and cider-nrepl that wasn’t matching. Is that a correct memory, @alexyakushev?

Yeah, we still do that. However, regarding Orchard, there is no such warning. We treat Orchard as integral part of cider-nrepl, and users generally shouldn't set the Orchard version manually.

I don't really have an opinion. My only concern with using "latest" versions was caching of dependencies from deps.edn (using RELEASE or LATEST) but that doesn't apply here right? Calva is running code to figure out the actual latest versions (at startup?) and then using that for any jack-in operations, right? I generally use the very latest available versions of every dev-only dependency -- knowing that I may well run into the sort of bugs @arthurfucher mentions but also knowing that I can debug/fix those fairly easily.

The supply chain paradox is that every time anything is blindly updated to latest, there is a risk of malware. We naturally mitigate the risk by choosing carefully the version of the key dependencies and relying on them likewise to screen the transitive dependencies.

The other half of the paradox is that we (average beneficiaries of open-source) are preoccupied with our own art and usually do not particularly relish intervening to pin or override the version of any one transitive dependency out of the hundreds that our own art might be built on. Rather, we may like a degree of stability (reproducibility), a likelihood to be using the same versions as everyone else, etc.

Hm!!! I think the pictured settings UX improvement could make people not need a "suggest some version numbers" command. That is: you become aware of a reason to update (which means you may know a version number) and your brain stem quickly decides "do I pop open the familiar, easy-to-reach settings or do I hunt for the weird command" in favor of the VS Code settings UI.

The help needn’t be a command. Like @seancorfield suggests we can print the latest versions in the repl output destination on jack-in, same style as we print it to Calva says today (and should keep printing, I think). What versions are being used, and what are the latest versions.