Remove the need to hardcode absolute paths for some entries in `.cabal/config`: support xdg home variables

[KholdStare]

Hi!

I keep all my configuration files on github to have an easily reproducible environment on all my machines. I keep my .cabal/config file in there as well, and don't like the fact that some absolute paths have to be hardcoded (e.g. remote-repo-cache, world-file and build-summary). This is inconvenient if $HOME happens to be different on various machines (e.g. work vs home).

Some possible solutions (which could be wrong):

• Expand ~ in paths.
• Expand environment variables from the shell (perhaps even very specific ones)
• Allow usage of $prefix in all paths

If one of the above suggestions is worthwhile, I'd be up for implementing it. Just let me know :smile:

Thank you!

[mrak]

I would like this, too. Just the ability to reference $HOME or $XDG_* variables would greatly improve the portability of my config

[chris-martin]

Would someone with a commit bit mind weighing in on whether a patch would be accepted for this?

[hvr]

I generally like the idea, but under the condition we do not open up support for arbitrary environment variables.

I'd concretely suggest to add support for a couple additional $-variables

• $home via System.Directory.getHomeDirectory (if we want, we could support ~/ as sugar
• $xdg_data / $xdg_config / $xdg_cache (via System.Directory.getXdgDirectory)

which I believe should address most use-cases without bringing into scope an unknown set of new variable names, while allowing for reasonably platform independence (thanks to directory abstracting over platforms and having reasonable semantics on e.g. windows)

The downside of allowing env-variables to affect the paths in the cabal config is that file-change-monitoring gets slighlty more complicated, but by using an explicitly enumerated set of input variables (i.e. $home /$xdg_{data,config,cache}) this remains simple enough.

[sboosali]

yeah, I agree w.r.t. a fixed of environment variables. and the ~ sugar.

one issue is which environment variables are chosen for Windows (which is far as I know, isn't part of the XDG BaseDirs spex). For example, the standard implementations between Haskell and Racket differ (see below). I'd stick with whatever directory does (or if Cabal has its own XDG utilities, those), but I wanted to mention it.

Haskell (directory package):

• $XDG_CONFIG_HOME — %APPDATA%
• $XDG_DATA_HOME — %APPDATA%
• $XDG_CACHE_HOME — %LOCALAPPDATA%

Racket (basedir package):

• $XDG_CONFIG_HOME — %LOCALAPPDATA%
• $XDG_DATA_HOME — %LOCALAPPDATA%
• $XDG_CACHE_HOME — %TEMP%

https://docs.racket-lang.org/basedir/index.html http://hackage.haskell.org/package/directory-1.3.3.2/docs/System-Directory.html#t:XdgDirectory

[23Skidoo]

645 seems to be another duplicate of this ticket.

[merijn]

The downside of allowing env-variables to affect the paths in the cabal config is that file-change-monitoring gets slighlty more complicated, but by using an explicitly enumerated set of input variables (i.e. $home /$xdg_{data,config,cache}) this remains simple enough.

Do any of the filepath fields in ~/.cabal/config affect the hash of packages? Or just the file-change-monitoring?

[Mistuke]

https://github.com/haskell/cabal/issues/4597 is also a duplicate of this. There was a large discussion there about the migration issues. But I think with new-build we can avoid that as it's a new thing anyway.

But the short story is on Windows we shouldn't use %AppData% for anything other than cabal config file because this is a synced directory.

[23Skidoo]

What's a synced directory on Windows? Synced across all users or backed up in the cloud?

[Mistuke]

Synced across active directory. It's a roaming profile folder. So it's synced back to the Ad server on login and logout. The data cabal puts there are often not useful on another machine but the sheer size of this folder makes network user's login and logout very slow as it has to sync and eats away at your profile quota. This affects most corporate environments and universities.

In newer versions of Windows this has been made more explicit in the folder resolves to a "Roaming" path to point this out more.

[23Skidoo]

Thanks, it's clear now.

[Mikolaj]

This is related to #680 that is now being worked on.

[athas]

Would people be opposed to just supporting $home? I don't think such a simple feature should be conflated with the general problem of variables.