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
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.
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.
Should be possible to implement just by hiding all non-add-source packages.
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.
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.