New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Cabal sandboxes relocatable #2302

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

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?

@jarlg

This comment has been minimized.

Show comment
Hide comment
@jarlg

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

jarlg 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

This comment has been minimized.

Show comment
Hide comment
@2piix

2piix Dec 30, 2014

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

2piix commented Dec 30, 2014

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

@christiaanb

This comment has been minimized.

Show comment
Hide comment
@christiaanb

christiaanb Mar 14, 2015

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.

Collaborator

christiaanb commented Mar 14, 2015

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.

@BardurArantsson

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Nov 7, 2015

Collaborator

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

Collaborator

BardurArantsson commented Nov 7, 2015

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

@bmjoan

This comment has been minimized.

Show comment
Hide comment
@bmjoan

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

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

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Dec 2, 2015

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

Collaborator

BardurArantsson commented Dec 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@christiaanb

christiaanb Dec 2, 2015

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.

Collaborator

christiaanb commented Dec 2, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@BardurArantsson

BardurArantsson Dec 5, 2015

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.

Collaborator

BardurArantsson commented Dec 5, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@BenBals

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

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