Skip to content

Provide some mechanism for refreshing changing projects #45

Open
mightybyte opened this Issue Nov 28, 2011 · 3 comments

3 participants

@mightybyte

This issue is similar to issue 36. The problem is that I'll be working on something in say the snap package that involves unreleased code from the rest of the snap framework. In the snap project directory, I will have done add-source for local copies of snap-core, snap-server, heist, etc. Then I'll modify something in one of those projects and I want the changes to show up when I build the snap project. I don't want to delete the whole sandbox, because then the build will take forever. My usual practice is to dig inside the sandbox directory, specifically delete files having to do with the changed project, then issue add-source for that project again.

The reason I'm opening a new issue instead of just commenting on issue 36 is because being warned about it isn't really a big problem for me. I usually know when something changed, and I want to refresh it. Ideally the add-source action would just detect changes and do the right thing. I realize that could be difficult. A simpler solution that would be completely acceptable would be to add a "-f" flag to the add-source action that would force the reload of said project.

This is a big issue for me. I run into this all the time with the Snap framework and other proprietary projects I'm involved with that use multiple projects not on hackage. Improving the workflow here would be a big win.

@gregwebs

why do you need to delete anything? doesn't add-source properly overwrite existing added packages?

I sent a pull request for #44 which adds an add-source-list command which may make your workflow a little better.

Have you tried the workaround mentioned in the SO answer?

@mightybyte

No, it doesn't overwrite...at least not when I've ever tried it. I haven't tried the workaround mentioned in SO because the extra command line argument would probably reduce productivity almost as much as that manual removal I do already. Having a cabal-dev config file in ~/.cabal-dev or similar might help with this.

Hmmm, on second thought, it might be nicer to have it search the current directory or a .cabal-dev file, and if it doesn't exist, check each parent directory successively. That would make it easy to do the right thing for different sets of related projects.

Update: As I just commented on SO, that workaround doesn't seem to work for me either.

@dukedave
dukedave commented Jan 3, 2012

I just knocked up the following bash script which emulates the "add-source -f" behaviour mentioned in the OP: https://gist.github.com/1557244

The assumption is that you have some cabal-dev sandbox directory (SANDBOX_DIR in the script), and in there you have a directory sdist which contains sdist tarballs.

Note that this script assumes you're using GHC and build with the currently installed version on your PATH, also its behaviour is undefined if you have multiple versions of a package in sdist installed in your sandbox.

Feel free to fork and improve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.