Skip to content
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

Implement independent goals #2500

Merged
merged 13 commits into from
May 21, 2015
Merged

Implement independent goals #2500

merged 13 commits into from
May 21, 2015

Conversation

edsko
Copy link
Contributor

@edsko edsko commented Mar 27, 2015

This is the next PR in the quest for setup dependencies, and implements independent goals and linking, as described in detail in the blog post

Qualified Goals in the Cabal Solver

This does not change any user observable behaviour -- in particular, we do not make independent goals available to the user as a command line argument (though we could); but having the infrastructure there will be essential for treating setup dependencies as independent, as well as a number of other features that can be built on top of this. One of those features will be base-3-shim support, so that we can change away from using the top-down solver as a default under certain circumstances. That however will be the topic of a later PR.

dcoutts and others added 11 commits March 27, 2015 15:38
It turns out not to be the right solution for general private
dependencies and is just complicated. However we keep qualified
goals, just much simpler. Now dependencies simply inherit the
qualification of their parent goal. This gets us closer to the
intended behaviour for the --independent-goals feature, and for
the simpler case of private dependencies for setup scripts.

When not using --independent-goals, the solver behaves exactly as
before (tested by comparing solver logs for a hard hackage goal).
When using --independent-goals, now every dep of each independent
goal is qualified, so the dependencies are solved completely
independently (which is actually too much still).
POption annotates a package choice with a "linked to" field. This commit
just introduces the datatype and deals with the immediate fallout, it doesn't
actually use the field for anything.
This is implemented as a separate pass so that it can be understood
independently of the rest of the solver.
In particular, in the definition of dependencyInconsistencies.

One slightly annoying thing is that in order to validate an install plan, we
need to know if the goals are to be considered independent. This means we need
to pass an additional Bool to a few functions; to limit the number of functions
where this is necessary, also recorded whether or not goals are independent as
part of the InstallPlan itself.
Since we didn't really have a unit test setup for the solver yet, this
introduces some basic tests for solver, as well as tests for independent goals
specifically.
@edsko
Copy link
Contributor Author

edsko commented Mar 27, 2015

Cc @dcoutts , @kosmikus .

@edsko
Copy link
Contributor Author

edsko commented Mar 27, 2015

Oops, sorry, forgot to add a module to other-modules again. Added now.

@kosmikus
Copy link
Contributor

I'll try to review this early next week. Please ping me again if you don't hear back then.

@23Skidoo
Copy link
Member

There are some failures on 7.4.2/7.6.3:

tests/UnitTests/Distribution/Client/Dependency/Modular/Solver.hs:495:13:

Not in scope: data constructor `Proxy'

tests/UnitTests/Distribution/Client/Dependency/Modular/Solver.hs:495:22:

Not in scope: type constructor or class `Proxy'

Leaving this PR for @kosmikus to review.

@23Skidoo
Copy link
Member

BTW, I very much enjoyed reading your blog post and I think that the work you're doing on Cabal is very cool.

@kosmikus
Copy link
Contributor

I see you've fixed the compatibility problems by adding a tagged dependency. While adding dependencies to cabal-install is generally ok, it still has a cost. I wonder if it's worth it in this case. And if we decide to add it, we probably have to fix the bootstrap.sh script as well.

@edsko
Copy link
Contributor Author

edsko commented Mar 28, 2015

@kosmikus Only reason I felt okay to add it as a dependency is because it's only necessary for the test suite, not for cabal-install itself (and since the test suite already depends on tasty, which depends on tagged, it's not actually a new dependency).

@edsko
Copy link
Contributor Author

edsko commented Mar 28, 2015

@23Skidoo Thanks! Glad you liked the blogpost :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants