Make Cabal sandboxes relocatable #2302

Open
2piix opened this Issue Dec 25, 2014 · 9 comments

Projects

None yet

8 participants

@2piix
2piix commented Dec 25, 2014

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":

    do
    darcs clone
    cabal sandbox init
    cabal install

    do
    cp sandbox
    fix bug
    darcs push

  • 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?

@giraj
giraj commented Dec 26, 2014

@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.

@2piix
2piix commented Dec 30, 2014

I see, thank you. I still want it, but I see it isn't a simple change. :)

@christiaanb
Collaborator

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.

@ttuegel ttuegel added this to the _|_ milestone Apr 24, 2015
@BardurArantsson
Collaborator

Is there anything actionable left in this issue or can it be closed?

@bmjoan
bmjoan commented Nov 30, 2015

@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

dependency: "/usr/lib64/postgresql/9.3/lib"
is not relative to the installation prefix:
"/home/joanbm/Projects/Haskell/playground/.cabal-sandbox"
cabal: Error: some packages failed to install:
postgresql-simple-0.4.10.0 failed during the configure step. The exception
was:
ExitFailure 1

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.

@BardurArantsson
Collaborator

@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...)

@christiaanb
Collaborator

@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.

@BardurArantsson
Collaborator

@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.

@BenBals
BenBals commented Mar 26, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment