pkg: remove context arguments

[Alizter]

We remove the --all-contexts and --context arguments from various package commands. Their usage in the tests has been replaced with the equivalent --workspace arguments.

• fix Simplify CLI for handling lock directories #9324

They are replaced with positional lock directory arguments as suggested in #9324. It's quite natural for all our package commands to use this term, so I have put it in Pkg_common and simplified how we select lock directories in various commands.

[rgrinberg]

Instead of a --workspace argument, it can be just a position argument pointing to the desired lock directory.

[Alizter]

I originally missed #9324 so I haven't implemented the positional arguments. I'll mark this as draft and finish implementing it.

[Alizter]

@gridbugs This is now ready to be reviewed. Let me know if you have any questions.

[gridbugs]

So it looks like the default behaviour of commands like dune pkg lock is to run for all lockdirs now, but you can pass lockdirs as anonymous arguments to have it run for just those lockdirs. I find that a but surprising as I thought we had a concept of a default lockdir which would be the target of commands unless otherwise specified. Since most other languages only allow a single lockfile per project, I think most users will expect that unless otherwise specified, commands that operate on lockdirs will only operate on a single lockdir. Plus considering command line tools in general when presenting a choice between a subset of options to users it's pretty rare for the default to be choosing everything. Usually if no elements are specified on the command line it's either an error or there's a conservative default behaviour.

My preference is for it to operate on the default lockdir when no lockdirs are specified and to allow anonymous args overriding which lockdirs are operated on, and add a flag --all which causes it to run on all lockdirs.

[Alizter]

My motivation for defaulting to all commands is that dune build will build targets in all contexts. Granted, we aren't coupling contexts to lock dirs any longer, so this might be misleading, but I think it is something that would be more intuitive for users.

@gridbugs Would you agree that the default behaviour of positional arguments is something we can decide on at a later time? We can follow up in an issue and discuss the pros and cons on either behaviour. I don't think it should prevent this PR from being accepted however.

[gridbugs]

My motivation for defaulting to all commands is that dune build will build targets in all contexts. Granted, we aren't coupling contexts to lock dirs any longer, so this might be misleading, but I think it is something that would be more intuitive for users.

I don't think the comparison to the way dune build treats contexts is apt since the main focus of that command is the target(s) being built. A more analogous comparison would be the way dune build treats targets, falling back to the @default alias when no targets are specified and having the user opt-in to building all targets via the @all alias.

@gridbugs Would you agree that the default behaviour of positional arguments is something we can decide on at a later time? We can follow up in an issue and discuss the pros and cons on either behaviour. I don't think it should prevent this PR from being accepted however.

The same could be said about any feedback regarding UX. Is there something in particular about this behaviour that merits merging it now and deferring further discussion? Are people blocked on this PR?

[Alizter]

I'll change the default behaviour to dune.lock, but the disadvantages are:

• dune.lock might not even be used by any context
• It's harder to select all lock files (we will have to add an --all argument complicating the CLI further).

[Alizter]

@gridbugs I've changed it so that it defaults to dune.lock and added a --all argument. This required some changes to dune describe pkg lock since we need to load the workspace in order to find all the lock directories to support --all.

[gridbugs]

Thanks @Alizter