Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Open
chowells79 opened this Issue · 3 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
Collaborator

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
@23Skidoo
Collaborator

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

@dcoutts
Collaborator

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
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.