Backport deprecation warnings to 2.2

[typedrat]

I was already working on this, but seeing @lspitzner's concerns in #5358 made me decide to wrap it up and make a PR.

To help ease the transition to 3.0 and the default new-build future, this backports the aliases and most importantly the warnings to ensure that people have time to update any scripts to use the aliases before the semantics would change.

Before this gets merged/released, if it does, I do want to come up with a list of all commands that need new- versions before 3.0 so that there will be all relevant warnings included.

--

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

[phadej]

why bump Cabal?

[phadej]

Oh, I see, added symbol. That should require third digit bump, patch (4th) level isn't enough.

[typedrat]

Seems to have an error in the travis script, but I'm not sure how that works.

[typedrat]

Commands that should also get warnings:

• sdist
• outdated
• doctest
• copy, register are likely not being replaced (based on my understanding, at least), but still
• reconfigure
• hscolour?

[23Skidoo]

cabal hscolour will be killed in favour of Haddock's built-in colourising.

[typedrat]

I know, but not sure if that should come with a warning or not.

[23Skidoo]

I've just merged a PR adding a warning to hscolour. Only to master though.

[typedrat]

Any that I'm not thinking of?

[23Skidoo]

sandbox? It also will be eventually removed in favour of new-build.

[typedrat]

Okay, adding those. Should I also backport 6922cfc in this PR?

[23Skidoo]

Please do.

[quasicomputational]

If sdist and outdated are printing warnings, what should the warning message tell users to do instead? AFAIK we don't have new-style equivalents to those yet; until we have a concrete 'here's what you can do to future-proof your code and make this warning go away' suggestion, I don't believe they should warn.

[typedrat]

Without sdist install won't work, so it'll be there by the time it changes. outdated? IThere's #4831. And anyway, their suggested option is to switch to v1-sdist and v1-outdated, because the warning is only on the unprefixed versions.

[quasicomputational]

There's still a nag for the v1- versions. On HEAD:

$ cabal new-run -v0 cabal -- v1-build --help
Compile all/specific components.

[...]

The v1-build command is a part of the legacy v1 style of cabal usage.

It is a legacy feature and will be removed in a future release of cabal-install.
Please file a bug if you cannot replicate a working v1- use case with the new-style
commands.

I could get behind the suggestion that sdist should warn but v1-sdist should be totally nag-free until new-sdist is in. I don't understand the interaction with install; if new-sdist is going to be implemented on the way then this works out, but I do think having a nag for things that don't have replacements will be the best way to get users to ignore the nagging and not upgrade in good time.

[typedrat]

Okay, I'll not give them to outdated since that's just a nebulously planned thing. new-sdist is required to implement new-install, so it's coming soon.

I mean, that warning is extremely not wrong and it only shows up in --help... I wonder if just wording it differently would work.