Enforce qualified constraints in the dependency solver. #4257

grayjay · 2017-01-22T20:21:04Z

This PR is a continuation of #4236. I made two changes to ConstraintScope before enforcing the constraints in the solver:

I removed the Namespace from the ScopeQualified constructor. This change doesn't affect the behavior of the solver, because we currently don't use Namespace anywhere.
I added a ScopeAnySetupQualifier constructor to allow constraints to apply to all setup scripts. The new constructor is only used internally in this PR.

This PR also adds dependencies with version ranges to the solver DSL. I ended up not needing the version ranges for these unit tests, but I left them because I think they could be useful.

/cc @robjhen @kosmikus

EDIT:

/cc @dcoutts @23Skidoo @ezyang @Ericson2314 @hvr @phadej

Here is a summary of the changes, from the changelog:

Added qualified constraints for setup dependencies. For example,
--constraint="setup.bar == 1.0" constrains all setup dependencies on
bar, and --constraint="foo:setup.bar == 1.0" constrains foo's setup
dependency on bar (part of Constraint syntax is not expressive enough. #3502).
Non-qualified constraints, such as --constraint="bar == 1.0", now
only apply to top-level dependencies. They don't constrain setup or
build-tool dependencies. The new syntax --constraint="any.bar == 1.0"
constrains all uses of bar.

mention-bot · 2017-01-22T20:21:06Z

@grayjay, thanks for your PR! By analyzing the history of the files in this pull request, we identified @kosmikus, @edsko and @dcoutts to be potential reviewers.

grayjay · 2017-01-27T08:48:49Z

Since the release is coming up, I wanted to figure out what changes relating to qualified constraints we should include. I can see three options that wouldn't take long to implement:

Disable the parsing of setup qualified constraints so that no changes go into 2.0. We'll be able to choose the syntax later, possibly after we have component-based solving.
Merge this pull request so that we have these changes in 2.0:
- new setup qualified constraints, such as foo:setup.bar == 1.0
- Non-qualified constraints, such as bar == 1.0, only apply to top-level dependencies.
- There is no longer a way to constrain build tool dependencies, or all setup dependencies, which means that a user can't prevent cabal from installing a particular package.
Merge this pull request and add a new syntax for constraints that apply to all dependencies. The previous PRs added that type of constraint but only used it internally. They are currently displayed as any.bar == 1.0 in the log.

I prefer 1 and 3, because I don't want to take away the ability to constrain any dependency.

23Skidoo · 2017-01-27T10:55:43Z

@grayjay

I prefer 1 and 3, because I don't want to take away the ability to constrain any dependency.

+1 from me. If we can implement 3 in time, then let's go with 3, otherwise we can postpone merging this PR.

ezyang · 2017-01-27T22:10:39Z

OK, I'm going to mark this as action-required for now. @grayjay, are you on point for (3)?

grayjay · 2017-01-28T19:40:02Z

Yes, I'll try to implement (3) this weekend. I'll add it to this PR.

This commit changes the meaning of constraints like 'pkg > 5'. Previously, 'pkg > 5' only applied to the top-level 'pkg' goal without a 'Namespace', but now it applies to any top-level goal for 'pkg'. However, the 'Namespace' field is currently only used by --independent-goals, so this change has no effect on behavior.

I used the new constraint scope to enforce the minimum Cabal version in setup scripts that lack a 'custom-setup' stanza. It isn't exposed to users yet.

…dency graph. For example, --constraint="any.pkg == 5" applies to "pkg" whether it is a top-level dependency, setup dependency, or build tool dependency. I also modified the UserConstraint type so that it is more similar to the PackageConstraint type, now that both types need to express similar "constraint scopes".

For example, "setup.Cabal installed" forces cabal to use the installed Cabal library for all setup scripts.

grayjay · 2017-01-30T05:45:59Z

I exposed the constraints that apply to all dependencies, as well as constraints that only apply to setup dependencies. The current syntax is:

--constraint="setup.Cabal >= 1.24" - constrain Cabal in all setup scripts
--constraint="any.Cabal >= 1.24" - constrain all uses of Cabal

Ericson2314 · 2017-01-30T15:45:46Z

@grayjay this looks great! ~~But say there is a package called setup or any? 😛 That would cause problems in my full-qualifier-paths future.~~

edit Er nope, because lib dependencies cannot be constrained, unless we get full private lib dependencies. By that point, I think we'll have full component-base solving too.

grayjay · 2017-02-01T06:43:42Z

@Ericson2314 Thanks for reviewing the syntax. Maybe we should reserve the package names "any" and "setup" to allow more flexibility for future changes to constraint syntax.

Ericson2314 · 2017-02-01T15:09:58Z

@grayjay well I'm thinking we can use my arrow notation with * and ** wildcards which can express everything, and then we won't need anything behind what we currently have as short-hands.

If we can reserve package names at this point, that's cool, though.

ezyang · 2017-02-03T22:43:53Z

I went ahead and merged this. Hopefully we can reserve any/setup in the near future; I don't actually know how to go about doing this.

23Skidoo · 2017-02-03T23:28:47Z

Someone who's familiar with hackage-server code needs to step in.

grayjay · 2017-02-05T03:07:20Z

Thanks!

@grayjay well I'm thinking we can use my arrow notation with * and ** wildcards which can express everything, and then we won't need anything behind what we currently have as short-hands.

I'm not sure I understand. Are you suggesting using asterisks instead? Then we would have something like *.Cabal or **.Cabal instead of any.Cabal.

Ericson2314 · 2017-02-09T06:12:49Z

@grayjay err nah I wasn't trying to subtly imply that :).

I was thinking if all single constraint path edges can be written (component -> component), * could be a wildcard within the component, and ** could be a wildcard over 0 or more edges.

any.foo = **.foo
setup.foo = **(*->*:setup).foo

** does subsume any (I assume any can only be used at the beginning unlike ** though), but any may still be nice to have as a more-discoverable English term that mirrors setup.

hvr · 2017-07-10T07:02:06Z

Hopefully we can reserve any/setup in the near future; I don't actually know how to go about doing this.

Someone who's familiar with hackage-server code needs to step in.

@23Skidoo @ezyang Fyi, since yesterday, Hackage rejects package names such as "all", "setup", "any" or "none"

Ericson2314 · 2017-07-10T13:03:51Z

Great!

grayjay · 2017-07-15T18:47:27Z

Thanks!

grayjay added the cabal-install: solver label Jan 22, 2017

grayjay force-pushed the enforce-qualified-constraints branch 2 times, most recently from 93e42ff to df67466 Compare January 22, 2017 23:02

ezyang added the blocked: action-required label Jan 27, 2017

grayjay added 10 commits January 29, 2017 16:10

Add a constraint scope to constrain a given package in any setup script.

f7b43f9

I used the new constraint scope to enforce the minimum Cabal version in setup scripts that lack a 'custom-setup' stanza. It isn't exposed to users yet.

Enforce qualified constraints in the dependency solver.

36ba5a4

Add constraints to solver DSL.

8bc9f4f

Add dependencies with version ranges to solver DSL.

67fab27

Add unit tests for qualified constraints.

46dbe4a

Add regression test for issue haskell#4154.

abac841

Update changelog.

0536f44

Expose constraints that apply to any setup dependency.

ff4c548

For example, "setup.Cabal installed" forces cabal to use the installed Cabal library for all setup scripts.

grayjay force-pushed the enforce-qualified-constraints branch from df67466 to ff4c548 Compare January 30, 2017 00:26

grayjay removed the blocked: action-required label Jan 30, 2017

ezyang merged commit 9aa4b9f into haskell:master Feb 3, 2017

grayjay deleted the enforce-qualified-constraints branch February 5, 2017 03:07

This was referenced Feb 5, 2017

new-build dependency solver failure with GHC 7.0 #4154

Closed

Cannot find solution with +parsec on Cabal, with cabal-install HEAD #4299

Closed

grayjay mentioned this pull request Feb 26, 2017

Constraint syntax is not expressive enough. #3502

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enforce qualified constraints in the dependency solver. #4257

Enforce qualified constraints in the dependency solver. #4257

grayjay commented Jan 22, 2017 •

edited

Loading

mention-bot commented Jan 22, 2017

grayjay commented Jan 27, 2017

23Skidoo commented Jan 27, 2017

ezyang commented Jan 27, 2017

grayjay commented Jan 28, 2017

grayjay commented Jan 30, 2017

Ericson2314 commented Jan 30, 2017 •

edited

Loading

grayjay commented Feb 1, 2017

Ericson2314 commented Feb 1, 2017

ezyang commented Feb 3, 2017

23Skidoo commented Feb 3, 2017

grayjay commented Feb 5, 2017

Ericson2314 commented Feb 9, 2017 •

edited

Loading

hvr commented Jul 10, 2017

Ericson2314 commented Jul 10, 2017

grayjay commented Jul 15, 2017

Enforce qualified constraints in the dependency solver. #4257

Enforce qualified constraints in the dependency solver. #4257

Conversation

grayjay commented Jan 22, 2017 • edited Loading

mention-bot commented Jan 22, 2017

grayjay commented Jan 27, 2017

23Skidoo commented Jan 27, 2017

ezyang commented Jan 27, 2017

grayjay commented Jan 28, 2017

grayjay commented Jan 30, 2017

Ericson2314 commented Jan 30, 2017 • edited Loading

grayjay commented Feb 1, 2017

Ericson2314 commented Feb 1, 2017

ezyang commented Feb 3, 2017

23Skidoo commented Feb 3, 2017

grayjay commented Feb 5, 2017

Ericson2314 commented Feb 9, 2017 • edited Loading

hvr commented Jul 10, 2017

Ericson2314 commented Jul 10, 2017

grayjay commented Jul 15, 2017

grayjay commented Jan 22, 2017 •

edited

Loading

Ericson2314 commented Jan 30, 2017 •

edited

Loading

Ericson2314 commented Feb 9, 2017 •

edited

Loading