Disambiguate options and commands

[ttuegel]

As I am refactoring the command-line flag handling code, I have noticed that many commands have "options" which fundamentally change the mode (operation) of the command. For example, consider the register command; it has three separate modes and two of them don't actually register the package! This is probably confusing to the user and it's certainly messier to implement.

I propose splitting all the "modes" out into their own commands, so that all the "options" are actually options. I think Cabal 2.0 is the ideal time to introduce such changes that break command-line compatibility.

[ezyang]

I've thought about this, but it's not very practical:

1. The current command line interface requires a lot of boilerplate to add a new command. We need to add a new CommandUI (registerCommand), a new command action (registerAction, which consists of fairly repetitive but slightly different code), pre/current/post hooks for the command (preReg, regHook, postReg), and a new flags data structure for the command (RegisterFlags). And there's probably some more I forgot.
2. cabal-install still needs to support the old way of doing things in perpetuity, because custom Setup scripts can depend on old versions of Cabal which wouldn't have the new command. So you wouldn't actually be able to delete most of these options from the data structures because cabal-install would still rely on them to talk to old Setup scripts.

But this is Haskell! We're all about building abstractions and reducing boilerplate. Maybe there is something we can do here.

[ttuegel]

cabal-install still needs to support the old way of doing things in perpetuity, because custom Setup scripts can depend on old versions of Cabal which wouldn't have the new command. So you wouldn't actually be able to delete most of these options from the data structures because cabal-install would still rely on them to talk to old Setup scripts.

At some point, we will have to do one of two things:

1. Decouple cabal-install's rendering of command-line flags from those data structures, or
2. Build wrappers linked against the older Cabal to talk to older Setup scripts.

If we don't do one of these two things, we can never, ever move forward. (For the record, this is why you may have seen me publicly declaring unpopular opinions like, custom Setup scripts were the biggest mistake ever.)

[ezyang]

Oh I hear you. See these bugs:

• nix-local-build is too tightly coupled to ConfigFlags, etc. #3549 nix-local-build is too tightly coupled to ConfigFlags, etc.
• Lessons learned from Custom #3065 Lessons learned from Custom

Decoupling the flags is a good idea; I'd support it.