Totally different UX in a rewrite?

[Olical]

So v2.0 is kinda sitting around on master but I'm not in sync with it, I'm thinking of diving into it to get it across the line and resolve everyone's issues but I'll need to set aside a day or two for it.

While I'm at it, I was thinking of completely overhauling the UX and wondered what people thought:

• Check local deps.edn as well as the one in the home dir if it's there. I don't think the root one Clojure installs should be touched?
• Fully interactive prompt by default that walks through one dep at a time in the main :deps then tells you when it's moving onto an alias.
• You can accept the change, skip, skip to the next section / file or skip all.
• Shows you a final plan that you can execute or bail out of.
• Has flags to do a dangerous "JUST DO EVERYTHING", exclude home dir, do nothing and just show what it could upgrade...

My main idea here is that it means you consider each change on it's own, that was you pick what you want to update without a clever combination of flags you're never going to remember. It means you see each change and consider them all which should be a little safer.

I will still need to put some work into which versions get picked and when though, I'll bear that in mind.

What do you think, @lverns, @seancorfield? I'll probably reuse the majority of the code, just restructure it to make this plausible.

The goal is to not require any CLI flags, it's all interactive and discoverable as you go. The flags would be for some blanket statements for stuff like "don't do anything, but check all versions for me".

I think the printing of where the version comes from (file / alias) is something that depot has been missing. I want it to display "you could upgrade clojure in your local deps.edn, but your home dir version is okay" essentially.

At the moment shadowing is the default, I'd like to avoid that.

[seancorfield]

I'm fairly strongly against anything which rewrites the project deps.edn even interactively. I just don't think it's the right approach -- and it's a minefield when you consider :override-deps from the "user" level to be honest.

I am even more strongly against rewriting anything in the "user" deps.edn file -- and be aware that the location of that file in terms of CLI behavior is controlled by the CLJ_CONFIG environment variable: you cannot just assume it's in the user's home .clojure folder!

The dependency version checking in 2.0 is broken as far as I'm concerned: it doesn't respect the CLI behavior like 1.8.4 did. Changing that was a mistake.

And I'm not picking on Depot 2.0 here: any t.d.a.-based tooling that does not respect the CLI behavior, in terms of discovery and merging of dependencies is just plain broken, so that applies to some of the other t.d.a. tooling out there as well. If the tool's behavior does not match the CLI behavior, it's wrong.

[lverns]

@Olical The proposed change would make the default CLI behavior something I don't normally expect. My preference for this sort of tool is that it default to being non-interactive and simply print the changes available for me to manually apply, but I think if you made depot behave the way you've described in this issue, and made it work well, I'd probably be content with it.

It sounds like you'd be tackling #32 in all these changes, which (in my mind) is the thing preventing the release of v2.

I think the printing of where the version comes from (file / alias) is something that depot has been missing.

Agreed. However, this may be the hardest part to implement since I'm not sure that t.d.a. exposes the necessary information through its API.