Skip to content

Sandboxes will install from hackage if locally-added source doesn't fit the constraints. #1648

Open
chowells79 opened this Issue Jan 13, 2014 · 4 comments

4 participants

@chowells79

If you add a local source location to a cabal sandbox, cabal will still install the package from hackage if the local version doesn't satisfy constraints and a version on hackage does.

I tested this by modifying a project to uselessly depend on one of my libraries, then adding its source to the cabal sandbox, and updating its version number.

$ cabal sandbox add-source ../nano-cryptr
$ cabal install --dependencies-only --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
nano-cryptr-0.1.1.3 (latest: 0.2.0.0)

The version 0.2.0.0 exists in my local source only. 0.1.1.3 is the latest version on hackage. The .cabal file for the current project restricted the version of nano-cryptr to < 0.1.2.

I'm strongly of the opinion that if you add a local source, it should constrain builds in that sandbox to getting the package it contains only from the local source. If the constraints end up not being satisfiable, it's an issue with the code being developed that needs to be corrected. Falling back to a version on hackage to satisfy constraints means you can fail to test the local code you were intending to test.

@dcoutts
Haskell member
dcoutts commented Jan 13, 2014

I agree. We should constrain things so that only the local instance can be picked.

@23Skidoo I remember something along these lines coming up when we were doing the code review. Remember where? If not, presumably we have the info available at the right point when we're building the inputs for the solver.

@23Skidoo 23Skidoo was assigned Jan 13, 2014
@23Skidoo
Haskell member

Should be possible to implement just by hiding all non-add-source packages.

@dcoutts
Haskell member
dcoutts commented Jan 13, 2014

Yes, though as an implementation detail constraining rather than hiding will lead to better error messages (once we merge the GSoC code for the better error messages) because it means the solver can see what the not-allowed alternatives are and so can explain why it cannot pick them.

@ttuegel ttuegel added the bug label Apr 23, 2015
@ttuegel
Haskell member
ttuegel commented Jun 27, 2015

There's another facet to this issue: add-source packages won't be used (even if they satisfy the constraints) unless their version number is greater than the version number of an already-installed instance of the same package. For example, our GHC HEAD test on Travis is failing right now because cabal-install is built against the Cabal-1.23 that comes with GHC HEAD, rather than the add-source Cabal-1.23 that coming from our repository.

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.