haddock: can't find a package database at <sandbox>

[UnkindPartition]

When I run cabal haddock in a non-sandboxed directory, I get the following error:

haddock: can't find a package database at /home/feuerbach/prog/haskell-names/.cabal-sandbox/ghc-7.6.1.20121207-packages.conf.d

(To make it clear, the directory where I run cabal haddock is not related to haskell-names.)

The reason why it can't find the database is that the sandbox has been deleted.

-v shows that indeed haddock was passed

'--optghc=-package-db' '--optghc=/home/feuerbach/prog/haskell-names/.cabal-sandbox/ghc-7.6.1.20121207-packages.conf.d'

I think that the proper solution is not to pass that package db at all (even when it exists), since it breaks sandbox isolation.

[UnkindPartition]

Aha. I found the reason. This package that I'm building docs for was add-source'd into haskell-names, so it was configured with its sandbox package database. cabal clean solved the problem.

It'd still be nice if that didn't happen, but I've no idea how to address it.

[UnkindPartition]

Perhaps add-source'd packages should be copied rather than built in place?..

[23Skidoo]

Perhaps add-source'd packages should be copied rather than built in place?

This way they'll have to be rebuilt from scratch each time, which is unrealistic. The point of add-source is that it tracks changes in the add-sourced directories. I guess we can run cabal clean on all add-source packages in cabal sandbox delete, except that won't help if you delete the sandbox with rm.

Again, add-source --snapshot would help here.

[UnkindPartition]

This way they'll have to be built from scratch each time, which is unrealistic.

Not necessarily. We could keep the build tree (*.o, *.hi etc.) and copy source files preserving modification time.

[23Skidoo]

copy source files preserving modification time

Is there a portable way to do this?

[23Skidoo]

In any case, copying will also introduce additional overhead on each build. Current behaviour is already annoying, and this will just make it worse. I think that implementing add-source --snapshot is a better way to work around this.

[23Skidoo]

...though if we decide to implement the smarter rebuild check I described in #1274, copying might become feasible (just copy over the files that have a newer timestamp than .cabal-sandbox/sandbox-timestamp).

[UnkindPartition]

I've got a new idea.

Copying the source files is not really necessary. It doesn't really matter where source files lie, as soon as we always want to use the latest version (which is not true for --snapshot — I realize it.). What we really want is just to use a different build tree (i.e. a different dist directory) to keep things hygienic. So a simple proposal could be:

• for cabal commands inside that directory, use dist as we've always done
• if we're building something in that directory for the purpose of a sandbox, use dist-$ID, where $ID could be a hash of the sandbox path, for example.

Would it make things any easier for you?

[23Skidoo]

@feuerbach I like this idea. We will still use copying for things like --snapshot and references to git repos.

@tibbe, what do you think?

[23Skidoo]

@feuerbach
On second thought I think this won't work. --builddir is set at configure time, so if you try to build an add-sourced project after the sandbox has been deleted, you'll still get an error.

[UnkindPartition]

But a different dist directory would also have its own setup-config. So sandboxes wouldn't even have a chance to interfere with ordinary cabal commands and with each other.

[23Skidoo]

@feuerbach You may be right, I need to test this.

[tibbe]

I think people shouldn't be using the same source directory for different sandboxes. It's confusing (modifying the source for the purpose of one project will affect the other). If we accept that we should be fine using the builddir in the add-source:d package's dir. This might require some retraining for a few people, but I think it's worth it.

Alternatively we could try to use the builddir of the current package for all building. This makes sense when we move to a less current-package centric world where the builddir will probably be in a directory that doesn't contain any packages.

@dcoutts thoughts?

[23Skidoo]

Alternatively we could try to use the builddir of the current package for all building.

I'm not sure this won't lead to conflicts. I think something like .cabal-sandbox/dist/$PACKAGENAME-dist is better.

[23Skidoo]

modifying the source for the purpose of one project will affect the other

If the source a git clone then I think it should be fine. Although I'd like to support this case directly in the future.

[tibbe]

I'm not sure this won't lead to conflicts. I think something like .cabal-sandbox/dist/$PACKAGENAME-dist is better.

Yes, that's what I had in mind. We should still compile the current package in dist as users will expect that dir to be there.

[tibbe]

If the source a git clone then I think it should be fine. Although I'd like to support this case directly in the future.

What I meant is that the following is a bad idea:

mkdir proj1
git clone https://github.com/bos/text.git
cd proj1
cabal add-source ../text
$EDITOR ../text/SomeSource.hs
cabal build

# Some time later:
mkdir proj2
cd proj2
cabal add-source ../text
$EDITOR ../text/SomeSource.hs
cabal build

As changes made to text for the purpose of proj2 happened to affect proj1. The user probably wanted to clone the text repo twice, once for each project.

[23Skidoo]

As changes made to text for the purpose of proj2 happened to affect proj1.

This may or may not be a bad idea, depending on the circumstances. E.g. a company can have a bunch of patched libraries intended to be used by all projects in the source tree.

[tibbe]

This may or may not be a bad idea, depending on the circumstances. E.g. a company can have a bunch of patched libraries intended to be used by all projects in the source tree.

That's totally fine. Those patches would be checked into the source tree. What I'm saying is not the greatest idea is to share local modifications (i.e. not checked in) between two local checkouts of two different projects.

[23Skidoo]

What I'm saying is not the greatest idea is to share local modifications (i.e. not checked in) between two local checkouts of two different projects.

Yes, I guess that could be confusing. The behaviour described in the first post is also confusing.

I should say that I like this idea better than copying. We'll still use copying (or tarballs, like cabal-dev) for --snapshot.

[23Skidoo]

Also, using the builddir in the add-sourced package dir won't by itself prevent the users from reusing the same source directory for different sandboxes. We'll have to come up with additional checks.

[UnkindPartition]

It's confusing (modifying the source for the purpose of one project will affect the other).

I don't think it's confusing — it's doing precisely what the user has asked. Yes, users can make mistakes, but you can't prevent all of them. If you force the user to have two separate source trees, it is as likely that she will make changes to the wrong tree, or make changes to one when both need that change.