Remove legacy code from code base

[mpickering]

Cabal and cabal-install have a large amount of legacy code.

Much legacy code for supporting different Haskell compilers, which is surely bitrotted at this point (untested on CI)

• Support for UHC
• Support for GHCJS
• Support for Haskell Suite

v1-commands have been deprecated for a long while

• Remove v1-commands

nix support is also legacy and unused to my knowledge

• Remove nix support

Please contribute to this issue by listing any other legacy parts of the code base which should be removed.

The cost of these code paths is real, they must also be updated when performing refactoring or other improvements (see #10256 for example).

[alt-romes]

I'm very much in favour of this. Even if some of these are more contentious, surely we can make progress on the undisputed ones.

Cabal should become rid of legacy baggage before growing new features, IMO.

[ulysses4ever]

There are many issues discussing parts of this meta-issue and they should be referenced, I think. Esp. regarding v1 and nix.

[geekosaur]

People are definitely still using both v1-commands and ghcjs.

[andreasabel]

@mpickering wrote:

[ ] Remove v1-commands

Relevant issue collections include:

• https://github.com/haskell/cabal/issues?q=label%3A%22re%3A+v1-install%22
• https://github.com/haskell/cabal/issues?q=label%3A%22re%3A+v1-vs-v2%22

On the danger of repeating myself: I first want to see feature completeness of v2 over v1.
One main limitation for me is that v2-install will unconditionally rebuild all modules, in contrast to v1-install or v2-build. Thus, it is unfeasible to run an automatic git bisect process based on cabal v2-install.
However, in our agda-bisect tool we need an efficient way of generating for the current bisecting point an Agda executable that we can pass to a script that runs some test on this version of Agda. And Agda accesses data-files so the context should also be correct (something one does not have to worry about with v1-install).
One resolution for me would probably if one could invoke cabal run from somewhere outside of the project, but a respective feature request has not been fulfilled:

• Option giving the project root directory #8037
• Unnecessarily difficult to run executables from outside of project #7940

Update: cabal run --project-dir=... works now (!); I could evaluate again if this will work in our context.

[ulysses4ever]

Hackage builder still uses V1 command afaiu. It may be a great bite-size task to solve before doing away with V1. Almost gsoc size, maybe.