---
title: Help test XDG support in cabal-install
description: If the next version of cabal-install breaks horribly, then it is probably my fault.
---

Cabal, or more precisely `cabal-install` which is mostly known to
Haskellers as the `cabal` command line program (["cabal" means four
things](https://gist.github.com/merijn/8152d561fb8b011f9313c48d876ceb07)),
recently merged a [pull
request](https://github.com/haskell/cabal/pull/7386) that makes
`cabal` support the [XDG Basedir
Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).
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](https://github.com/haskell/cabal#ways-to-build-cabal-install-for-everyday-use)
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.