Need some clarification re qualifiers and linking #3706
Comments
|
I'll take a stab at answering these. Using a constructor with two package names sounds fine. It might be better to name it something other than "Exe", though, since we could also add a qualifier for top-level executables.
It would be nice to have at least a few levels of qualification to avoid collisions, but I don't think it's necessary. One level of qualification here is probably no more restrictive than the existing qualification depth limit on setup dependencies. The solver's cycle detection should prevent the two Cabals from being linked. Do you have the -v3 log from that run? I would expect the solver to link the two Cabals' dependencies, leading to the cycle Now that #3662 is merged, is there a need for the dependency solver to solve for individual components rather than packages? |
|
Log is below. (You can repro yourself by gegtting Cabal HEAD and running it on cabal-install.) I am not 100% sure how to interpret these logs but maybe there is no linking happneing. I chatted with Duncan and he said that it might be a preference problem: there is an inplace Cabal and we try to use it for setup dependencies even though we shouldn't (nothing to do with linking.) |
|
Thanks. It looks like
I'm not sure how we should determine which goals should be built with the local version of a package. Does it make sense to always rank the local version last for setup dependencies and build tools? I can see how that behavior might be confusing if someone wanted to use the local version everywhere, though. Preventing the linking wouldn't be enough to fix the problem, because we could remove the single instance restriction, which would allow the local version to be built twice. |
|
Clearly, there needs to be a way for a user to specify, in Or we could consider the inverse: here the use of vendored Cabal is undesirable because we just wanted the vendored Cabal to be used as a library dependency for cabal-install, and nothing else. Perhaps Cabal is a special case and so we should put something in our |
|
I agree; there needs to be a way for the user to specify which version to use. I prefer always defaulting to the inplace package, because it's more consistent. #3502 discusses qualified constraints. |
|
Thanks, I'll close this for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey @grayjay, @edsko, @kosmikus ,
I was recently working on some solver changes (the commits are the tip of #3662) and I had a few questions:
happyandalex, I want Cabal to dependency solve for these separately (they shouldn't interfere with each other, nor my library dependencies.) The way I did this was by introducing a new constructor toQualifier,Exe PackageName PackageName, which indicates that the package p1 has a dependency on an executable from package p2. First, is this the right way to do this? Second, this is only one level of qualification (since @edsko reverted arbitrarily wrong qualifications because it caused solver loops). Should I make this qualifier recursive?Cabal, which happens to have a dependency on something that useshappy, which itself uses Cabal (as a setup dependency). Is there a way to tell the solver to NOT link these two Cabal's? I've observed that sometimes the solver decides happy should be built in place, which makes me a sad panda (not a happy panda).Thanks!
The text was updated successfully, but these errors were encountered: