Remove legacy command v1-freeze

[yvan-sraka]

Hello everyone! This is a humble attempt to begin cleaning up the Cabal codebase by removing outdated chunks of code. The ideal starting point for this task seems the removal of legacy v1 commands. I am more than willing to contribute by eliminating most of them, but I'm curious to know if there are users still relying on them (perhaps on v1-build?). Thus, I've decided to start small with only the removal of v1-freeze. Are there any strong objections to this initiative? If not, what are the other v1 commands that could be removed?

---

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.
• Include manual QA notes if your PR relates to cabal-install.

Bonus points for added automated tests!

[ffaf1]

Should this be removed too?

cabal/cabal-install/src/Distribution/Client/Setup.hs

Lines 1432 to 1436 in d5f98df

	freezeCommand :: CommandUI FreezeFlags
	freezeCommand =
	CommandUI
	{ commandName = "freeze"
	, commandSynopsis = "Freeze dependencies."

[Mikolaj]

@yvan-sraka: hello! Thanks a lot for you initiative. Unfortunately, some users still depend on v1- commands. If you know for a fact that v1-freeze is not used by anybody, e.g., it's broken for a long time or completely subsumed by v2-freeze, then please state that claim and it would be great to get rid of it. For a list of likely users of v1-, ask around in the tickets from the https://github.com/haskell/cabal/projects/12 and https://github.com/haskell/cabal/projects/10 projects.

[andreabedini]

Thank @yvan-sraka for tackling this problem; as you are aware it is not much of a technical problem but also a social one :-)
I believe v1-freeze is a good starting point but also @Mikolaj suggestion is fair. I suggest you (we?) review the two boards that @Mikolaj linked to any reference to v1-freeze (or, indirectly, its functionality). Then perhaps we can open a discussion on discourse?
@Mikolaj what do you think of this plan?

[ulysses4ever]

@andreabedini I just went over those boards and I don't think there's anything about freeze in particular (worth double-checking though). Mikolaj puts rather high bar: v1 version is hardly broken (although I don't know much about it), so our best bet would be to check that v2-freeze supersedes v1-freeze. I kinda doubt that this is the case but worth checking.

[andreabedini]

Mikolaj puts rather high bar: v1 version is hardly broken (although I don't know much about it), so our best bet would be to check that v2-freeze supersedes v1-freeze.

Perhaps a good approach could be to start drafing a migration guide from v1-freeze to v2-freeze. This would help us pick missing use cases if there are any.

[Bodigrim]

@Mikolaj I think you are putting a very high bar here. All contributors to Cabal pay an ongoing tax for the arcane complexity of legacy modes codebase. Doing this indefinitely just because someone potentially might still be using them strikes me as an unfair bargain. Staunch users of v1-, if any, can just stick to older versions of cabal-install or vouch to contribute money / time to maintain them.

I have not seen any conscious users of v1- for a couple of years.

[ulysses4ever]

I totally support all points made by @Bodigrim but...

I have not seen any conscious users of v1- for a couple of years.

There are, sadly, some important ones. From the top of my mind:

1. Hackage (what?! yes!!)
2. @ivanperez-keera
3. Not sure if @andreasabel switched Agda (and all other projects he cares about) to v2 completely, but at some point there were troubles, I think.

The issue is, v2 is still not feature-complete w.r.t. v1 [citation needed, please search the bug tracker]. I personally don't think this should hold back the v1 purge. But it makes it hard to argue with current v1 users.

[Bodigrim]

https://agda.readthedocs.io/en/latest/getting-started/installation.html#using-cabal suggests that Agda migrated to v2-install.

[Bodigrim]

For the reference, hackage-server ticket is haskell/hackage-server#1173, which refers haskell/hackage-server#821 (comment), which refers #6876 and #6811.

That said, AFAIU hackage-server cares about v1-install only. And if I remember correctly, @ivanperez-keera use case was about v1-install too, not about anything else.

[ivanperez-keera]

I have not seen any conscious users of v1- for a couple of years.

The infrastructure we have at NASA for haskell regularly uses v1- commands.

I've seen this in other companies in the wild too (still to this day), and that includes v1-freeze.

[ulysses4ever]

agda.readthedocs.io/en/latest/getting-started/installation.html#using-cabal suggests that Agda migrated to v2-install.

I'm not talking about what they suggest to the users, I'm talking their internal dev jobs,e.g.:
https://github.com/agda/agda/blob/be28b6e2edc3961292eb9e56f80080289d90c61f/Makefile#L265-L268
I think there was something about haddocking too.

[ivanperez-keera]

I think there was something about haddocking too.

It's hard to remember the specifics until I encounter this again, but I remember having to rely on v1- commands to generate haddocks.

I also found it easier to do benchmarking using v1- commands in Yampa (ivanperez-keera/Yampa#167 (comment)), but I admit that there may be an equivalent v2-.

[Bodigrim]

But it makes it hard to argue with current v1 users.

You don't have to argue, this is an open-source development. Anyone unhappy with upstream decisions can maintain a fork, if they wish.

I don't mean to be dismissive to @ivanperez-keera or @andreasabel (and I hugely respect both!), but unless there is an announced timeline to decomission, it's unlikely the remaining users of v1- would put much effort into migration to v2-, and rightfully so. Do we commit to maintain v1- forever?

If I were you, I'd dedicate a stable branch of cabal-install (say, 3.10) to be kept on life support, receiving updates mandatory to use new versions of GHC, but nothing else. This should be reasonably simple: after all ghc --make interface does not change that often. (The existence of Custom builds and necessity to communicate with Setup.hs of future versions of Cabal-the-library complicates things, but hopefully not too much.) In such case cabal-install-3.12+ can safely drop v1- commands, while users of legacy pipelines keep using cabal-install-3.10.{3,4,5} without any disruption.

[Kleidukos]

If I were you, I'd dedicate a stable branch of cabal-install (say, 3.10) to be kept on life support, receiving updates mandatory to use new versions of GHC, but nothing else.

We can add this to the agenda for next week's meeting.

[gbaz]

I think lowering the bar and considering removing v1-freeze is fine, and other non-central v1-commands as well perhaps.

We know there are existing gaps in v2-install and v2-build, and those are real gaps, and having a full timetable to sunset all v1 commands at this time would be just poor stewardship.

Existing non-solved gaps in the v2- featureset are not something that maintainers should "put users on a clock" for or otherwise blame users for. Personally, as a maintainer, I have a lot of difficulties in navigating parts of the cabal codebase, but it is never the v1-commands to blame.

[ulysses4ever]

cabal-install-3.12+ can safely drop v1- commands

This sounds like it can be done overnight, but I'd like to hear informed estimates. I'm pretty sure there's not enough humanpower around cabal development these days to pull this out, even if there's a consensus. Even harder to propose any timeline and be sure that it won't share the previous timeline's fate (namely, the proposer burned out and left active cabal development altogether).

[gbaz]

I would note there are existing problems with v1- install that will accumulate over time -- notably its lack of support for mutliple public libraries, build-tool-depends, etc. These will be "push" factors that continue to drive people away from v1- and towards v2- even without maintainers spending precious cycles actively making things worse :-P

[Mikolaj]

A few relevant tickets (please add more to the projects): https://github.com/haskell/cabal/projects/12 https://github.com/haskell/cabal/projects/10

I think the crucial one is #6481. You can read there (or linked) about numerous (as in dozens or hundreds per month, I guess) end users who are not programmers and who do cabal v1-install on Windows as part of a music synthesiser installation and update (I hope, not operation).

@Bodigrim: the bar for all v1- commands other that v1-install may be, in fact, quite low, because most are unused and/or identical to v2. However, we'd need to put in some work to determine the status of each. I think this has already been started, IIRC for v1-freeze and there's a ticket and/or PR.

Edit: heh, I'm writing this comment in the very PR. :D

[ivanperez-keera]

The following tries to be straight and to the point, but I don't want it to be taken as rude. I appreciate the effort from the contributors and maintainers taking care of these tools, which we don't have to put time into.

but unless there is an announced timeline to decomission

@Bodigrim I'm unsure about what you mean by this. If you mean a timeline to remove v1- support, that would not be a factor driving us to move to v2-.

In my view, the reasonable way to approach decomissioning v1 would be to check what v1- commands people are still using and why, and provide v2- alternatives that address their needs and use cases. When those are present, people can move away, and after we can remove them safely.

[andreasabel]

@Bodigrim wrote:

@Mikolaj I think you are putting a very high bar here. All contributors to Cabal pay an ongoing tax for the arcane complexity of legacy modes codebase. Doing this indefinitely just because someone potentially might still be using them strikes me as an unfair bargain. Staunch users of v1-, if any, can just stick to older versions of cabal-install or vouch to contribute money / time to maintain them.

I strongly object.

I have not seen any conscious users of v1- for a couple of years.

I am.

Dear folks eager to remove v1-features: Please invest your energy into making v2 a complete alternative to v1 first.
The issues are to be found on this bug tracker (look for labels v1-vs-v2, v1-install etc.). Maybe start with this one:

• cabal install run immediately after cabal build unnecessarily rebuilds the project #6919