This is a minor feature request. I've done some experimentation and it all seems to work, but I haven't read or written any Cabal source code.
I would like Cabal sandboxes to be relocatable. Effectively, this means that the sandbox would be unaware of its location in the file system. As far as I know, this should not be a problem, since the sandbox only points to files inside its container.
Here are some use-cases:
pre-built sandboxes, ready for development. Sandboxes are super-cool, and I have been enjoying them since before the state of the Haskell union survey that one year when I suggested cabal-dev and everybody listened. (Sorry, I am proud of my very minor contribution to computing history. :-) But there's no denying that having to wait for sandboxes to build all the time is not fun. But if we can just build a sandbox and clone it when we need it, we can pay for it once. This would be especially useful for projects with lots of "movement":
cabal sandbox init
making an OS X bundle seems to be a plist file away. Make the plist point at dist/bin/foo, and bob's your uncle.
I tried an experiment where I built a sandbox and set cabal.config to point to .cabal-sandbox instead of /home/foo/bar/baz/.cabal-sandbox. Afterwards, I made a copy of the sandbox, went into it, and ran cabal repl. It worked perfectly.
It seems to me (keeping in mind that I have not read sources and defer to your opinion) that all we'd have to do is change the default sandbox configuration emitter to not prefix directory names with the current working directory. Is that sensible? Is there something else I'm missing?
@2piix Yes, cabal repl seems to work after making the paths relative, but most things else break (try a cabal install if you're not convinced). See #1490 and #1542.
I see, thank you. I still want it, but I see it isn't a simple change. :)
It was pointed out to me that I should perhaps leave a comment in this thread. Cabal 1.22 is shipped with preliminary support for so-called relocatable (or prefix-independent) packages. What his currently enables you to do is to have a completely relocatable .cabal-sandbox directory. This means you can move/copy the entire .cabal-sandbox directory anywhere you want on your machine.
To get a relocatable .cabal-sandbox dir just do:
cabal sandbox init
cabal install --dependencies-only --enable-relocatable
I know this doesn't get you completely what you describe in the issue, but I'm sure this new aspect of sandboxes will help in ultimately achieving it.
Is there anything actionable left in this issue or can it be closed?
@BardurArantsson Some packages with external FFI library dependencies fail to install as relocatable in sandboxes.
For example cabal install --enable-relocatable postgresql-simple unexpectedly fails with
cabal install --enable-relocatable postgresql-simple
is not relative to the installation prefix:
cabal: Error: some packages failed to install:
postgresql-simple-0.4.10.0 failed during the configure step. The exception
The path to PostgreSQL's libpq.so is get from pkg-config.
I see no reason why full paths to external libraries are not allowed.
@joanblake I think that would be a separate (more "focused") issue... would you mind creating an issue for that?
(Though, I think it might somewhat go against the idea of relocatability to use absolute paths... but then again external dependencies technically aren't part of the sandbox, so...)
@joanblake Indeed, when I created partial support for prefix-independent packages, it didn't cross my mind that there might be external, non Haskell, libraries that a package could depend on. I don't know if we can currently distinguish between the library paths of Haskell and non-Haskell libraries. I guess creating a separate issue indeed makes sense.
@BardurArantsson This issue cannot be closed, because the cabal-sandbox.config files are not prefix-independent. They still contain absolute paths.
@christiaanb Ah, I forgot about that. If that's the only thing missing, perhaps create a specific issue for that bit? (Unless of course you're actively working on this and we're just a PR away... in which case creating a different issue would be pointless.)
My thinking here is that issues should be as specific (i.e. non-vague) as possible to encourage others (who may not familiar with the overall plan) to be able to contribute.
I recently had to move a Haskell project featuring a cabal sandbox and updating all paths in cabal.sandbox.config using a simple find and replace in a text editor fixed all errors for me. Well at least cabal run still works fine. Will have to see about installing new dependencies.