Using the --reinstall flag with cabal-dev

I'm working on the wxHaskell library, and wishing to keep my development work sepa开发者_如何学运维rate from the stable wxHaskell from hackage I'm using cabal-dev in the following manner:

1. I obtained the source for wxHaskell from darcs;
2. Because wxHaskell is comprised of three components I used cabal-dev add-source to add each one (wx, wxcore, wxdirect);
3. I was then able to install into a sandbox local package library by doing cabal-dev install wx, as expected, the dependencies were detected and everything built and installed.
4. Finally I successfully ran my test code by using ghc -package-conf to specify the location of the sandboxed package database.

The problem comes when I make modifications to the wxHaskell source. In order to build and install the updated code I have to use cabal-dev install --reinstall, which makes sense as I don't increment the version number; the build takes place and I see "Installing library in..." and "Registering..." but the changes I've made in the code aren't present in the recompiled sandbox library.

The work around I have at the moment is to delete the cabal-dev library and repeat the process every time I want to rebuild.

UPDATE: cabal-install >= 1.18 has support for sandboxes, and will be better maintained than cabal-dev going forward. Cabal-install also has better support for using add-source with sandboxes. Here's a description of the new sandboxing features in cabal-install: http://coldwa.st/e/blog/2013-07-30-Cabal-sandbox.html

Old answer:

As you found, 'add-source' is not meant for use with actively changing projects. I'm not sure that there is a good solution there either - it's difficult to track the location of an add-source'd project (there is no existing infrastructure for that, at least), and I'm not sure that's always the right thing.

Another workflow may serve you better - just use cabal-dev install, pointing to the sandbox you wish to use for future development. Recent versions of the cabal toolchain (by which I mean Cabal, cabal-install and cabal-dev) allow for this sort of thing:

$ ls 
wx        wxcore          wxdirect
$ cabal-dev install --sandbox=<path-to-some-sandbox> ./wx ./wxcore ./wxdirect
...

(Note: I have not tested this with WX - kinks may arise that I'm unaware of!)

Assuming everything goes as expected, that will install the three packages from the local sub directories into the specified sandbox. Updating the source just means re-issuing a cabal-dev install command for the project that changed.

Keep in mind that you must either issue the repeated cabal-dev install commands in the correct order on your own, or you must use the batch command above and update version numbers accordingly.

I make no claims about this being ideal ;) but I think it's better than deleting the sandbox each time.

After some investigation I can confirm that this is a result of my misunderstanding regarding the usage of add-source, as detailed in "Using a sandbox-local Hackage" section of the README, which is given here (the strong was added by myself and indicates the reason for my misunderstanding):

Cabal-dev also allows you to use un-released packages as though they were on hackage with cabal-dev add-source.

For example, the linux-ptrace and posix-waitpid packages were only recently uploaded to hackage. Previously, cabal-dev was used to build applications that depended on these two packages:

$ ls
linux-ptrace/  myProject/  posix-waitpid/
$ cd myProject
$ cabal-dev add-source ../linux-ptrace ../posix-waitpid
$ cabal-dev install

Note that cabal-dev add-source accepts a list of source locations.

Be careful, however, because packages that have been added are not tied to their original source locations any more. Changes to the linux-ptrace source in the above example will not be used by myProject unless the user issues cabal-dev add-source with the path to the linux-ptrace source again. This is similar to the cabal install step you may do now to enable a project to make use of changes to a dependency.