RFC: Make nix-store packages relocatable

[hvr]

WIP: I've created this ticket so I don't forget to flesh it out with a few possible approaches

The basic idea/problem: we could easily have compiled nix-store packages made relocatable (and they're nicely self-contained in "$prefix/store/$compiler/$libname"), if Paths_$pkgname.hs would allow us to have a single variable for overriding the "$prefix/store" base-folder (strawman: "$CABAL_STORE_PATH"), rather than hardwirding the $prefix into each compiled artifact (to keep this simple, I'm going to ignore DSO-related path-relocability-issues).

TODO: describe minimal/specific variant, as well as a more general variant involving general var-name template interpolation scheme.

/cc @ezyang @dcoutts

[christiaanb]

Just want to point out there is some support for relocatable packages in Cabal already: #2255

http://qbaylogic.com/blog/2016/05/08/relocatable-sandboxes.html describes how the above PR gives relocatable sandboxes.

[phadej]

Questions:

CABAL_STORE_PATH (or just CABAL_STORE?) would be an environment variable, which

• would override store-dir setting in $CABAL_CONFIG / ~/.cabal/config?
• not overwrite --store-dir cli argument?

What if user have non-default store-dir: in $CABAL_CONFIG, then one would need to set CABAL_STORE_PATH?

Should the default cabal-store-path still be saved in Paths_$pkgname.hs by default anyway, with an (global, ~/cabal/config option) to disable its generation. Then "desktop users" could simply edit ~/.cabal/config to whatever they want, without need to touch envvars.
Taking even further: this "default cabal-store-path" could be configurable, so I can (in a build-box in the could) do

cabal new-build --store-dir=/store/build1235 --default-store-dir=/cabal/store

to produce artifacts with my local machine paths burned in (I do have /cabal/store) locally.

Even more bonus: default-cabal-store could expand $home, $xdg* variables. (related: #5998)

[phadej]

#5551 is a prerequisite

[phadej]

I think CABAL_STORE_PATH is a way to go, especially if we can generalise into multiple paths, e.g. CABAL_SEARCHPATH, a bit like:

• https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH
• https://docs.oracle.com/javase/tutorial/essential/environment/paths.html (CLASSPATH)

I don't know however how to not break stack too much, as it really spreads libraries all over the place (and Cabal cannot know the snapshot directory):

% cat ~/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/pkgdb/contravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF.conf
name: contravariant
version: 1.5.1
id: contravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF
key: contravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF
license: BSD-3-Clause
copyright: Copyright (C) 2007-2015 Edward A. Kmett
maintainer: Edward A. Kmett <ekmett@gmail.com>
author: Edward A. Kmett
stability: provisional
homepage: http://github.com/ekmett/contravariant/
synopsis: Contravariant functors
description:
    Contravariant functors.
category: Control, Data
abi: 5a66554bd24cb92d0325d4df85990bea
exposed: True
exposed-modules:
    Data.Functor.Contravariant.Compose
    Data.Functor.Contravariant.Divisible
    Data.Functor.Contravariant.Generic
import-dirs: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/lib/x86_64-linux-ghc-8.6.5/contravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF
library-dirs: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/lib/x86_64-linux-ghc-8.6.5/contravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF
dynamic-library-dirs: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/lib/x86_64-linux-ghc-8.6.5
data-dir: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/share/x86_64-linux-ghc-8.6.5/contravariant-1.5.1
hs-libraries: HScontravariant-1.5.1-5DqKSjbrRzZU8YLmfpGsF
depends:
    StateVar-1.1.1.1-2ewTKofpCGhC2np5dyFIaR base-4.12.0.0
    transformers-0.5.6.2
haddock-interfaces: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/doc/contravariant-1.5.1/contravariant.haddock
haddock-html: /home/phadej/.stack/snapshots/x86_64-linux/lts-13.23/8.6.5/doc/contravariant-1.5.1