Help test XDG support in cabal-install

Cabal, or more precisely cabal-install which is mostly known to Haskellers as the cabal command line program, recently merged a pull request that makes cabal support the XDG Basedir Specification. Previously, cabal would put all of its files in the ~/.cabal directory. Now the files are spread over multiple directories: * $XDG_CONFIG_HOME/cabal for the main configuration file. On Unix, this defaults to ~/.config/cabal. * $XDG_CACHE_HOME/cabal for downloaded packages and script executables. Defaults to ~/.cache/cabal on Unix. * $XDG_STATE_HOME/cabal for compiled libraries and other stateful artifacts. Defaults to ~/.local/state/cabal on Unix. * ~/.local/bin for executables installed with 'cabal install'. The advantage is mostly that cabal now behaves slightly more like other modern Unix tools. For example, it is easier to put all configuration files under version control if they’re all in the same subdirectory, and it is easier to delete all program caches when you’re low on disk space. This is obviously a rather invasive change. Does it mean that the next version of cabal will break your workflow? Maybe! But if so, it is not intentional. This change comes with what I hope is rather thorough backwards compatibility behaviour. Basically, if ~/.cabal exists, or $CABAL_DIR is set, the old behaviour of using a single unified directory will be maintained. And of course, most paths can still be configured manually in the configuration file. Still, because of the delicacy of a change like this, we’d like some external confirmation that cabal is still usable. This requires human trials. Therefore, if you are a human who uses cabal, please try installing the latest development version and see if it still works for you. If you want to try out the new XDG future, you can delete your ~/.cabal directory (possibly copying ~/.cabal/config to ~/.config/cabal/config first). I’ve been dogfooding this support for a over month, but I have no illusions about my usage covering the full feature space. Beyond whether cabal remains at all functional, I am personally curious whether the XDG simulacrum that is implemented on Windows is at all useful for Windows users, or whether it would be better for cabal to retain a single unified directory on that platform. Finally, on a meta note, this is my first contribution to Cabal. I previously heard horror stories about its code complexity, but I don’t think think they are warranted, at least not in the corner that I was touching. You certainly find relics of a long development process, including code necessary to support obsolete features (v1-build and sandboxes), but for a project its age and scope, I found the code both well structured and reasonably well documented. XDG support was added entirely by modifying cabal client code, without touching the Cabal library at all. -- \ Troels /\ Henriksen

On Sun, Oct 2, 2022 at 2:49 PM Troels Henriksen
Still, because of the delicacy of a change like this, we’d like some external confirmation that cabal is still usable. This requires human trials. Therefore, if you are a human who uses cabal, please try installing the latest development version and see if it still works for you. If you want to try out the new XDG future, you can delete your ~/.cabal directory (possibly copying ~/.cabal/config to ~/.config/cabal/config first). I’ve been dogfooding this support for a over month, but I have no illusions about my usage covering the full feature space.
Is there a convenient way to install this without doing a `git clone`? In particular I'd like a convenient way to manage it via `ghcup` as was provided for the 3.8.1.0 RC. -- brandon s allbery kf8nh allbery.b@gmail.com

Brandon Allbery
On Sun, Oct 2, 2022 at 2:49 PM Troels Henriksen
wrote: Still, because of the delicacy of a change like this, we’d like some external confirmation that cabal is still usable. This requires human trials. Therefore, if you are a human who uses cabal, please try installing the latest development version and see if it still works for you. If you want to try out the new XDG future, you can delete your ~/.cabal directory (possibly copying ~/.cabal/config to ~/.config/cabal/config first). I’ve been dogfooding this support for a over month, but I have no illusions about my usage covering the full feature space.
Is there a convenient way to install this without doing a `git clone`? In particular I'd like a convenient way to manage it via `ghcup` as was provided for the 3.8.1.0 RC.
As a side effect, Cabal's CI suite produces artifacts that contain (dynamically linked) 'cabal' executables. The following URL retrieves a zipfile that contains a tarball that contains 'cabal': https://github.com/haskell/cabal/suites/8566596132/artifacts/383133509 It may or may not work for ghcup. I assume that once actual release candidates are made, more easily-installable binaries will also be provided, as with previous releases. But that's probably six months or more away. -- \ Troels /\ Henriksen

Is there a migration path for converting to the new layout? The above
makes clear what happens to `~/.cabal/config` but only hints about
what I should do with other paths (e.g. `~/.cabal/store`). Or is the
preferred migration path to move the config file and nuke (or move out
of the way, as a backup) everything else?
On Mon, Oct 3, 2022 at 3:56 PM Troels Henriksen
Brandon Allbery
writes: On Sun, Oct 2, 2022 at 2:49 PM Troels Henriksen
wrote: Still, because of the delicacy of a change like this, we’d like some external confirmation that cabal is still usable. This requires human trials. Therefore, if you are a human who uses cabal, please try installing the latest development version and see if it still works for you. If you want to try out the new XDG future, you can delete your ~/.cabal directory (possibly copying ~/.cabal/config to ~/.config/cabal/config first). I’ve been dogfooding this support for a over month, but I have no illusions about my usage covering the full feature space.
Is there a convenient way to install this without doing a `git clone`? In particular I'd like a convenient way to manage it via `ghcup` as was provided for the 3.8.1.0 RC.
As a side effect, Cabal's CI suite produces artifacts that contain (dynamically linked) 'cabal' executables. The following URL retrieves a zipfile that contains a tarball that contains 'cabal':
https://github.com/haskell/cabal/suites/8566596132/artifacts/383133509
It may or may not work for ghcup. I assume that once actual release candidates are made, more easily-installable binaries will also be provided, as with previous releases. But that's probably six months or more away.
-- \ Troels /\ Henriksen
-- brandon s allbery kf8nh allbery.b@gmail.com

Brandon Allbery
Is there a migration path for converting to the new layout? The above makes clear what happens to `~/.cabal/config` but only hints about what I should do with other paths (e.g. `~/.cabal/store`). Or is the preferred migration path to move the config file and nuke (or move out of the way, as a backup) everything else?
Yes, nuke everything else. It'll require recompilation, but some of the Cabal devs expressed doubt that the store is even relocatable at all, as it may embed file paths (possibly in the hashes). -- \ Troels /\ Henriksen
participants (2)
-
Brandon Allbery
-
Troels Henriksen