Resolver Dev Syncup (5 May 2020)

Participants:

Agenda?

- YAML tests

[then... everyone gets into co-working mode]

pip UX and resolver team meeting note pad

(including May 5th and 7th collab time)

7 May collab time

* What do we want to focus on?

Something that could use funding:

pip UX and resolver team meeting note pad

5 May 2020

Pradyun and Nicole and Bernard

(with additional notes on 7 May in conversation among Bernard, Tzu-Ping, and Pradyun)

Dependencies

For pip resolver work we have 2 kinds of deps - build time and install time

build time

I need this thing Y so I can build Z

Install (run) time

Package X need this package Y when i run so that I work (needing requests to make network calls)

The dependency resolver project is delaing with install dependencies, not build time deps.

Pradyun has been working on how to visual dependencies.

The team don't know how to visual the complicated situations

The team doesn't know all the ways we can end up with conflicts, therefore its hard to give users useful feedback/notifications

Research opportunity - research with users

Exceptions

There are 3 main examples.

1. Resolution impossible: this conflict is not logically resolvable. Every choice we can make has a conflict. So the error message can be clear and specific.

Some algos exist to solve this exception - one is Pubgrub. Pubgrub is doing dep. resolv. it's maintaining a "graph of the status of compatibilities/incompatibilities". It then generates the error messages based on the final graph. Examples of the outputs here: https://github.com/dart-lang/pub/blob/master/doc/solver.md#examples and blogpost here: https://medium.com/@nex3/pubgrub-2fb6470504f

Right now pip isn't maintaining this pubgrub-esque compatibilities/incompatibilities graph. It is doable, but not there.

Research questions

Possible design deliverables

Error message content

We can create different levels of message

Terminology

pinning dependencies

Documentation

Document resolution strategies (Use these recommendations to users as possible ways to resolve them?)

Documentation on recommendations on pinning dependencies (e.g. you're less likely to see this issue if you have less pinned package versions) There are blogposts, can they be rolled into "if you don't know what to do, start with these options and these are the reasons why" trustable, good documentation. https://caremad.io/posts/2013/07/setup-vs-requirement and https://packaging.python.org/tutorials/managing-dependencies/

2. Resolution too-deep

This is computational expensive and takes a lot of time due to large search space. This means the resolver doesn't really know why it's failed. We're not sure how big an issue this is for users, and we're not sure of what usecases cause this exception.

So far there is only 1 reported case of too-deep.

The answer will probably be vague, due to the unknown space.

Here are some things we could do:

(Explanation: we really dont know the causes, maybe we should show stats ^ above. And let users then report those to the team. This wouldn't really help the user resolve the issue directly, but they can report them to the pip team and start the troubleshooting. If the team then gets enough understanding then possibly we can display the "useful" debugging information)

participant recruitment

Research questions

3. Requirement inconsistent: a build time bug. we can ignore this.

Problem statement

There are 2 exceptions - 1 and 2 above. Each has it's own need to 1) compute the error (figure out what information to present and 2) then present the information.

pip is able to work out which exception has occured.

The question is how do we compute the error message?

To provide an useful message to the user, it would be easier to know (otherwise we'll provide too many solutions - therefore being useless to fixing the problem) what the complications are (there is always more than one cause to the problem).

presenting the user:

If I ran out of milk and want to buy milk, to buy some I have to find my car key. Is the error I can't find my key, or i have no milk?

Goal: get milk

Tasks:

Example 1. Error: could not get milk, need car, cannot find car key

Example 2. Error: could not get milk, need car, cannot find car key. what about using bike?

Pradyun: the direction we're going in is doing what pubgrub does.

Resolver: i can't give you milk, because i can't give you transport

Building analygous reporting logic in pubgrub and using that instead

TZP: lets start with the simplest error message, gradually fill it out based on user feedback - "Error: could not get milk, cannot find car key".

examples pip get milk

Questions:

In order to figure out what information is to be presented to the user, we would investigate the conflict and choose one of our tools from our "toolbox" - what information to display.

For 1 and 2 we don't now what caused the error in most situations - we need to point them in the general direction of it. what we dont know is a) how to point and b) how to figure out how to compute those pointers.

We need to get the resolver fail cases in order to work out what data we can expose to the user in those cases and then devs work out whats possible to do.

Failure cases

How do we get them? They need to come from users ideally.

Expert approach

Use metadata

Possible design deliverables

Error message content

We can create different levels of message

Documentation

Document resolution strategies

General research questions

Project questions

Dependency resolution and PubGrub

https://pradyun.github.io/scrap/four.html

Nextsteps

Method 1

Method 2

PackagingWG/2020-05-05-pip (last edited 2020-05-18 14:58:35 by SumanaHarihareswara)

Unable to view page? See the FrontPage for instructions.