Can I install multiple versions of cabal at once?

I would like to do both ghcup install-cabal 3.0.0.0 and ghcup install-cabal 2.4.0.0 and have the installed binaries not conflict with each other. Currently they both get installed as ~/.ghcup/bin/cabal so the cabal from the command that was run most recently is the only one which will be installed.

Is there an option I can use to install them as ~/.ghcup/bin/cabal-x.x.x.x or similar? If not, is there somewhere where I can learn about the rationale for that design?

Why would you need two different cabal versions?

It could be for many reasons. Perhaps I want to test that my package builds properly with both cabal versions. Perhaps I run a large Haskell team and I want to incrementally upgrade them to a newer Cabal version. Perhaps a user tells me that a build has a bug with Cabal 2.4 and I have 3.0 installed.

This feature is not difficult to implement, the question is just if this is necessary.

It could be for many reasons. Perhaps I want to test that my package builds properly with both cabal versions.

Yeah, but again. Why would you?

Cabal versions are backwards compatible. This is not the case with GHC, so we have two entirely different scenarios. Old code is likely to break with newer GHC versions. Old cabal files not, afaik @hvr

Suppose I have 3.0 installed because I like to keep up to date. I'm developing a package and I want to check that my cabal file or some other aspect of my setup is compatible with 2.4. What would be the right way to do that?

Here's another use case: Suppose I am leading a Haskell team. I want to give my team specific instructions to install a specific set of tools. Once they have their tools set up I can tell them to run the command

~/.ghcup/bin/cabal v2-build --with-ghc ~/.ghcup/ghc/8.6.5/bin/ghc

If they tell me that the command runs but something goes wrong then I know it wasn't a problem with the GHC version: the specific GHC version is mentioned in the command line. But how do I know that they didn't install cabal 2.4 by accident? There's less capability to track down bugs here. Automation and reproducibility are widely considered to beneficial in software engineering. ghcup could help by installing cabal under particular name through which we can know which version is running.

Suppose I have 3.0 installed because I like to keep up to date. I'm developing a package and I want to check that my cabal file or some other aspect of my setup is compatible with 2.4.

Cabal (the file format) is versioned: https://www.haskell.org/cabal/users-guide/developing-packages.html#pkg-field-cabal-version

Cabal checks this. You cannot violate it.

However, the set of valid cabal command-line parameters is not versioned. They are an important part of the setup required to build a package. For example, if I try to run

 ~/.ghcup/bin/cabal v2-install --ghc-option=-Wwarn --with-ghc ~/.ghcup/ghc/8.6.5/bin/ghc --installdir=.

under 3.0 it works fine. If I try it under 2.4 it gives the following errors

cabal: unrecognized 'v2-install' option `--ghc-option=-Wwarn'
unrecognized 'v2-install' option `--with-ghc'
unrecognized 'v2-install' option `--installdir=.'

I would much rather give people instructions that say run ~/.ghcup/bin/cabal-3.0.0.0 ... because on failure they will receive the error message no such file or directory: ~/.ghcup/bin/cabal-3.0.0.0 and that is much easier for them to diagnose and resolve on their own.

But maybe I'm missing something here. Is there some reason that it's better for ~/.ghcup/bin/cabal to be mutable, and for specific versions of cabal not to be accessible by version-suffixed names (even though the GHC versions are)?

I would much rather give people instructions that say run ~/.ghcup/bin/cabal-3.0.0.0 ... because on failure they will receive the error message no such file or directory: ~/.ghcup/bin/cabal-3.0.0.0 and that is much easier for them to diagnose and resolve on their own.

If they have problems with cabal-install, the first thing you should tell them is to update cabal-install. Then you ask for the output of cabal --version. I don't really see any reason you would tell a user "please downgrade cabal". For GHC, that might in fact be the case (downgrading).

I see. Let's test my understanding. Does the reasoning go "Later versions of cabal are always at least as good as older ones (they support no fewer features and have no more bugs) therefore upgrading cabal is always the right thing to do."?

Does the reasoning go "Later versions of cabal are always at least as good as older ones (they support no fewer features and have no more bugs) therefore upgrading cabal is always the right thing to do."?

I think so.

I see. Thank you for clarifying.

closed

mentioned in issue ghcup-hs#23 (closed)