-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show constraint sources in dependency solver errors #10524
base: master
Are you sure you want to change the base?
Conversation
4811a3c
to
0c8471d
Compare
We have a lot of `showType` functions that are effectively a `Pretty` instance but less composable. Let's make them proper `Pretty` instances. Split off of haskell#10524
9ebbba8
to
522bec9
Compare
cabal-testsuite/PackageTests/NewSdist/MultiTarget/all-test-sute.out
Outdated
Show resolved
Hide resolved
cabal-testsuite/PackageTests/ConstraintSource/SourceRepositoryPackage/cabal.out
Show resolved
Hide resolved
@jasagredo just a heads-up: on the last Cabal meeting @9999years asked to not comment on their PRs while a PR is in the draft mode. I remember it because I’m guilty in it more than many! |
522bec9
to
e52d016
Compare
c10bd7d
to
9854c9d
Compare
Needs a release note. |
9492b41
to
b27b413
Compare
Added a release note and tests, addressed comments. Should be ready to go! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a pity 3.14.1.0 is breathing down our necks; it would be nice to see this go in, seems like it'd be a big UX improvement.
import Text.PrettyPrint | ||
|
||
-- | A package bundled with a `ConstraintSource`. | ||
data WithConstraintSource pkg = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this type being used as WithContraintSource UserConstraint
so I think pkg
is not actually a pkg
? i.e. constraintPackage
is misnamed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, constraintPackage
is often (but not always) a package. I wasn't sure of a better name for it. constraintInner
, maybe? constraintConstraint
is also somewhat misleadying, as it's a constraint source and not a UserConstraint
itself...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed them, how do these look?
constraintPackage
→constraintInner
constraintConstraint
→constraintSource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started reviewing this PR, but I had a question. It looks like a lot of the changes relate to adding ConstraintSource
s to targets in v2 commands. Why do the build targets need ConstraintSource
s? I had thought that targets for most commands only specified the subset of the project to build and didn't affect solving. The only exception I can think of is v2-install
, which can solve for packages outside of the project (e.g., "cabal install text-2.0
"), but then I would expect all targets to be able to use the same ConstraintSource
(ConstraintSourceUserTarget
), which I think is the current behavior on master.
cabal-install-solver/src/Distribution/Solver/Types/ConstraintSource.hs
Outdated
Show resolved
Hide resolved
cabal-install-solver/src/Distribution/Solver/Types/ConstraintSource.hs
Outdated
Show resolved
Hide resolved
cabal-install-solver/src/Distribution/Solver/Types/WithConstraintSource.hs
Show resolved
Hide resolved
=<< readTargetSelectors | ||
(localPackages baseCtx) | ||
(Just BenchKind) | ||
(map (\target -> WithConstraintSource{constraintInner = target, constraintSource = ConstraintSourceCommandlineFlag}) targetStrings) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this line use ConstraintSourceCommandlineFlag
as the ConstraintSource
? If I understand correctly, targetStrings
is a list of targets provided to the bench command, so ConstraintSourceUserTarget
seems like a better match. This comment also applies to many of the other commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll change it if you want. I think it's really unclear which is supposed to be which, and I have no clue what Cabal means when it tells me a constraint comes from a 'user target'. What is ConstraintSourceCommandlineFlag
for, if not command line arguments?
( WithConstraintSource | ||
{ constraintInner = | ||
NamedPackage (C.mkPackageName p) [] | ||
, constraintSource = ConstraintSourceUnknown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be ConstraintSourceUserTarget
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the targets
parameter should be replaced with one that contains constraint source information. Right now, the constraint source is unknown because that information is missing. We don't know what this function is getting called with or where the targets come from.
-- This is `my-lib` 0.9. | ||
source-repository-package | ||
type: git | ||
location: https://github.com/9999years/cabal-testsuite-my-lib.git | ||
tag: 9a0af0aa81325c71e744def11db06265840ffb5f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this test use an existing package in the Haskell organization as in the postCheckoutCommand
test?
cabal/cabal-testsuite/PackageTests/postCheckoutCommand/cabal.positive.project
Lines 3 to 8 in 02da008
source-repository-package | |
type: git | |
-- A Sample repo to test post-checkout-command | |
location: https://github.com/haskell/bytestring | |
post-checkout-command: true | |
tag: 0.10.9.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted a smaller repository so the tests would run faster; my repository is 136k vs bytestring is about 15m.
I also need a package that depends on a conflicting version of a library in the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grep for location:
in this repository and you'll see we're already cloning tons of non-Haskell org repos in the tests.
Could not resolve dependencies: | ||
[__0] next goal: my-lib (user goal) | ||
[__0] rejecting: my-lib; 2.0, 1.0 | ||
(constraint from cabal.project requires ==0.9) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly to the message in use-local-version-of-package.out
, I think that this message would be clearer if it explained that the constraint came from the version of a package listed in cabal.project
. It could also help to mention that it is a source repository package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to also change the content of this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, @jasagredo asked me to rename it #10524 (comment)
Before: [__0] rejecting: memory-0.18.0 (constraint from user target requires ==0.17.0) After: [__0] rejecting: memory-0.18.0 (constraint from cabal.project requires ==0.17.0)
From @grayjay: > The dependency solver currently doesn't describe preferences in error > messages, so I think that it would take a lot more work to make this > useful.
db60ab4
to
0546f08
Compare
...provided that nothing else changes.
e180d68
to
2844e3e
Compare
We have a lot of `showType` functions that are effectively a `Pretty` instance but less composable. Let's make them proper `Pretty` instances. Split off of haskell#10524
We have a lot of `showType` functions that are effectively a `Pretty` instance but less composable. Let's make them proper `Pretty` instances. Split off of haskell#10524
We have a lot of `showType` functions that are effectively a `Pretty` instance but less composable. Let's make them proper `Pretty` instances. Split off of haskell#10524
We have a lot of `showType` functions that are effectively a `Pretty` instance but less composable. Let's make them proper `Pretty` instances. Split off of haskell#10524
Before:
After:
First shot at #10519. Seems unavoidably large.
Builds off of #9578.
Future work: Propagate line numbers into these constraints!
Implementation strategy:
Propagate provenance (
ProjectConfigPath
/ConstraintSource
) into project config types (Distribution.Client.ProjectConfig
,D.C.ProjectConfig.Legacy
)Extract and attach that information in
D.C.ProjectConfig.findProjectPackages
Attach that information to
ProjectPackageLocation
(returned fromfindProjectPackages
). Note: Might be worth unifying that withPackageLocation
, would make the new typePackageLocationProvenance
.Use that information to write better
ConstraintSource
s into the solver; this is mostly implemented.Overall it seems like all the information exists, but it takes a lot of work to propagate it into the right parts of the system.