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

RFC: Begin Cabal development commentary #3990

Open
phadej opened this Issue Oct 17, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@phadej
Collaborator

phadej commented Oct 17, 2016

IMHO it can be a part of user's manual. Some topics to begin with are implementation commentary of

  • solver
  • backpack
  • new-build
  • parsec parser

@phadej phadej changed the title from Begin Cabal development commentary to RFC: Begin Cabal development commentary Oct 17, 2016

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
Member

23Skidoo commented Oct 17, 2016

@phadej phadej referenced this issue Oct 17, 2016

Merged

Parsec parser #3602

9 of 9 tasks complete
@phadej

This comment has been minimized.

Show comment
Hide comment
@phadej

phadej Oct 17, 2016

Collaborator

@23Skidoo didn't know about that!

Collaborator

phadej commented Oct 17, 2016

@23Skidoo didn't know about that!

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Oct 17, 2016

Contributor

This shouldn't stop you from working on it, but I have been working on a solver document. It is not very far along though.

Contributor

ezyang commented Oct 17, 2016

This shouldn't stop you from working on it, but I have been working on a solver document. It is not very far along though.

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Sep 8, 2017

Member

@ezyang BTW, what's the fate of that solver document? Maybe you can put your draft on the wiki if you're no longer working on it.

Member

23Skidoo commented Sep 8, 2017

@ezyang BTW, what's the fate of that solver document? Maybe you can put your draft on the wiki if you're no longer working on it.

@ezyang

This comment has been minimized.

Show comment
Hide comment
@ezyang

ezyang Sep 8, 2017

Contributor

Apparently, I only wrote the intro :)

.. highlight:: console

Whither dependency solving
==========================

Code bases with no external dependencies are easy to build: you just,
well, build everything.

But the usual project is not an island unto itself: rather, it is
composed from other packages written by a heterogenous set of authors.
Each of these packages has multiple versions which may or may not be
compatible with one another, giving rise to the nontrivial problem of
determining a set of packages which are mutually compatible with each
other.

How can you solve this problem?

- You could rely on some third party (Stackage) to tell you
  what your version assignment should be.

- You could pick some version assignment (e.g., the latest versions
  of everything), and then tweak it until you find an assignment that
  works.

- You could use a *dependency solver*, which automates the process of
  testing version assignments to find a satisfying assignment.

Generally speaking, you would rather use the first two approaches if at
all possible.  But sometimes there is no pre-existing version assignment
that is known to work, and the obvious "by-hand" assignments don't seem
to work.  In such cases, the dependency solver can be an extremely useful
tool for generating satisfying assignments.

What a dependency solver does
=============================

The dependency solver is a pure function of type ``DependencyResolver``.
The solver takes as input:

1. The platform we are building
Contributor

ezyang commented Sep 8, 2017

Apparently, I only wrote the intro :)

.. highlight:: console

Whither dependency solving
==========================

Code bases with no external dependencies are easy to build: you just,
well, build everything.

But the usual project is not an island unto itself: rather, it is
composed from other packages written by a heterogenous set of authors.
Each of these packages has multiple versions which may or may not be
compatible with one another, giving rise to the nontrivial problem of
determining a set of packages which are mutually compatible with each
other.

How can you solve this problem?

- You could rely on some third party (Stackage) to tell you
  what your version assignment should be.

- You could pick some version assignment (e.g., the latest versions
  of everything), and then tweak it until you find an assignment that
  works.

- You could use a *dependency solver*, which automates the process of
  testing version assignments to find a satisfying assignment.

Generally speaking, you would rather use the first two approaches if at
all possible.  But sometimes there is no pre-existing version assignment
that is known to work, and the obvious "by-hand" assignments don't seem
to work.  In such cases, the dependency solver can be an extremely useful
tool for generating satisfying assignments.

What a dependency solver does
=============================

The dependency solver is a pure function of type ``DependencyResolver``.
The solver takes as input:

1. The platform we are building
@hvr

This comment has been minimized.

Show comment
Hide comment
@hvr

hvr Sep 8, 2017

Member

@ezyang btw, your introduction makes it sound as if dependency solving was a kind of discouraged last-resort you should avoid whever you can... whereas dependency solving lies at the core of the Hackage/Cabal/PVP ecosystem... ;-))

Member

hvr commented Sep 8, 2017

@ezyang btw, your introduction makes it sound as if dependency solving was a kind of discouraged last-resort you should avoid whever you can... whereas dependency solving lies at the core of the Hackage/Cabal/PVP ecosystem... ;-))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment