Fix "source-repository-package breaks 'cabal v2-install'"

[fommil]

Fix #5643 which is a bigger bug than original reported: v2-install currently does not work at all if there are git packages. // @hasufell

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

[23Skidoo]

Would be nice if there was a test case.

[fommil]

@23Skidoo yeah, I would like that too. Where can I look to add one? I basically just need to run v2-install on a package definition that has a git source dependency.

[23Skidoo]

I'd look at the existing VCS tests.

[fommil]

@23Skidoo could you please point me to them in the repo?

[fommil]

I can confirm that this fixes the exception for me, but unfortunately it causes a recompile of my project (e.g. the originally reported repro). I'm not sure if that is a side effect of this fix, or if it is another bug in cabal. i.e. if I do cabal v2-build foo -O0 then cabal v2-install foo -O0 then I get two full recompiles.

git clone https://github.com/hasufell/example-cabal-project.git
cd example-cabal-project
cabal v2-build example-cabal-project 
cabal v2-install example-cabal-project --symlink-bindir=bin

[quasicomputational]

A PackageTest (in cabal-testsuite/PackageTests/; have a look in, e.g., NewSdist for examples of what they look like) should be able to exercise this code. I'd also suggest a test for new-sdist with a source-repository-package, which was also broken.

Is installing binaries from a source-repository-package the right thing to do, considering that regular dependencies off Hackage don't have binaries installed? Will this surprise users? See also #5586.

[fommil]

@quasicomputational adding a test seems to be the easy thing, but referencing a git repo that must permanently be available is another thing. Does one exist that I can use?

I think I've convinced myself to prefer a workflow based on v2-build rather than v2-install so I'm not sure what other people's expectations are. In my usecase I just want access to the binary, I don't care about sdists.

[quasicomputational]

I think we'll want to have a local git repository during testing, rather than hitting the network. Creating one as part of the test is probably the simplest route, so shell out to git init etc.

To be clear - you want to have a binary from the source-repository-package installed (i.e., copied to the symlink-bindir directory)? That's what the patch as written will do - i.e., it's treating the package from the git repo as local. I don't object to this exactly, but I just want to be clear on if this is desired behaviour or an implementation detail.

[hvr]

@quasicomputational The consequence in v2-install makes me think we really need the ability to control whether a git repo dep is considered local or non-local (as brought up in #5586); and I'd argue to make the default be to treat it as non-local as that's what imho is the less surprising default: In my POV, referring to git repos instead of hackage packages is mostly for the purpose of vendoring rather than treating them as part of your project proper.

[fommil]

I'm travelling and won't be able to work on this PR for a few weeks.