You can clone with
HTTPS or Subversion.
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.