commercialhaskell / commercialhaskell/stack
Can't force rebuilds of non-local packages
- Dominant language
- Haskell
- Stars
- 4.1k
- Forks
- 850
- Avg merge
- 10h 37m
- Merged PRs (30d)
- 4
Description
https://github.com/commercialhaskell/stack/issues/2805#issuecomment-263531315 reminded me of an issue I had recently but hadn't reported.
TL;DR. Sometimes you need to uninstall packages because they break somehow (because bugs) and you need to force a rebuild. I am 100% fine with "force a rebuild" if that's easier to implement. In fact, it'd be enough to extend `--force-dirty` (and its docs) to this use case.
```
$ stack install ghc-paths
Run from outside a project, using implicit global project config
Using resolver: lts-6.6 from implicit global project's config file: /Users/pgiarrusso/.stack/global/stack.yaml
$ stack install ghc-paths --force-dirty
Run from outside a project, using implicit global project config
Using resolver: lts-6.6 from implicit global project's config file: /Users/pgiarrusso/.stack/global/stack.yaml
$
```
Below I describe a crazy integration bug involving Homebrew, ghc-paths, and stack, as a concrete instance. This one might be Homebrew's fault but I'm not sure. I also realize I'm using a system GHC, but the plan is not to make that unsupported (since some users have valid use cases for that option and it makes sense to support them).
I use a system install of GHC 8.0.1, and installed it with Homebrew. Then, Homebrew updated it to version 8.0.1_1 (and then 8.0.1_2), which means some files were moved (they're now in `/usr/local/Cellar/ghc/8.0.1_2` rather than `/usr/local/Cellar/ghc/8.0.1`). But the GHC binary is still on the PATH, so 99% of packages don't care.
But I use intero. Which depends on ghc-paths. Which figures out those paths during the build, apparently—so they became invalid, and the Homebrew update broke intero.
So I had to uninstall ghc-paths to rebuild it. That was very challenging: I had to use `stack exec ghc-pkg unregister` (or some variation), but that wasn't enough because a new install fetched the compiled ghc-paths from some earlier snapshot. After a few tries, looking at verbose logs to figure out the involved earlier snapshot, I managed a clean reinstall. I sometimes removed the existing files by hand (after listing them with `stack exec ghc-pkg list`).
Yes, I know I could have nuked the entire cache, but many of you would probably find that annoying. Most users would only have that option, and I'm not 100% sure I don't have some silent corruption in the snapshot (though everything seems to work as expected).
I'm using stack 1.2.0 if that matters.
Contributor guide
Assessment
This issue has not been assessed yet.