7 May

Teamwide call

Participants:

• Ernest
• Ilan
• Paul
• Sumana
• Pradyun
• Tzu-Ping
• Bernard

TODO:

• TODO: Bernard and Nicole (see "# Nextsteps" below) -- they're identifying research participants and will implement the research method mentioned below -- giving them examples of error messages. Timeline: Nicole and Bernard are talking about it tomorrow, should have research participants identified by then, Nicole will have method fleshed out in more detail, can send out recruitment email Friday, responses by Monday. Have research finished .... will have a better idea tomorrow. Will be a few weeks. Earliest possible time we would get info back is ~2 weeks from now. Latest is more like a month

• TODO: Pradyun says: resolver team has to syncup & recap discussion with UX folks from earlier today, and see what's actionable right now. Zulip thread started to talk about one of those things. Will come up with more TODOs

• TODO: Sumana: start separate conversation about this. (release of beta)

Agenda:

• Near future (after end of pip contract commitment)
  • Bernard, Sumana, Ernest - still working on this through the rest of the year
  • Ilan: has another project with Quansight that he's moving on to
  • Paul: back to working on pip in volunteer time, and full-time work with Atos. No availability to extend contract beyond, say, July
  • Tzu-Ping: another project coming up, starting to get slightly involved. Will not be immediately available after this project. After things get calm there, will return to volunteer work
  • Pradyun: College graduation in August, moving to another city and starting at a new job in September. A decent amount of paid time at that job will involve open source. Expect to be able to continue to be on contract with PSF, barring occasional "too much happened today" -- expect to be able to keep up commitments in contract during the transition.
• Error messages
  • add text/narrative documentation around the test cases ...

    • https://github.com/pypa/pip/blob/master/tests/functional/test_new_resolver.py

      • test_new_resolver_no_dist_message
      • test_new_resolver_requires_python_error

      • Bernard, Nicole, and Pradyun started doing that in their phone call earlier. Moved to more of a conversation/Q&A rather than documenting in the test file. Part of the work Ilan has done has an overlap with that.... but does not cover space quickly.

  • adding more tests: Ilan has done this, including tests that have these conflicts. Ilan wrote comments about current error message & how it could be improved. Summarized all the things he has found in document shared on Zulip https://github.com/ilanschnell/pip/blob/yaml_conflicts/tests/yaml/ERRORS.md & Paul replied. See PR #8194

    • Ilan notes that he added more content to the main README https://github.com/ilanschnell/pip/blob/yaml_conflicts/tests/yaml/README.md

  • TP: We should add a test: about conflicting requirements. There are no tests re resolver emitting 2 things depending on different versions of the same dependency.
    • Pradyun: there is 1 YAML test, we need to expand it and make it better.
    • TP: if I read Ilan's PR right, then some of his tests is in this category
  • Next steps?
    • Paul: the 2 examples Ilan referred to ....how to report on dependency conflict is something we can work on providing. will need code changes -- we can develop an infra that gives us error msgs that someone thinks are a good way forward. That's given us something we can move forward on.

    • Pradyun & Bernard & TP talked about this today: we have a plan on how to get more user feedback. Implement those actionable messaging .... improve messaging based on user feedback

    • (If you want to see, see below: line 196-198 currently in Etherpad) (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".)
    • TODO: Bernard and Nicole (see "# Nextsteps" below) -- they're identifying research participants and will implement the research method mentioned below -- giving them examples of error messages. Timeline: Nicole and Bernard are talking about it tomorrow, should have research participants identified by then, Nicole will have method fleshed out in more detail, can send out recruitment email Friday, responses by Monday. Have research finished .... will have a better idea tomorrow. Will be a few weeks. Earliest possible time we would get info back is ~2 weeks from now. Latest is more like a month

    • TODO: Pradyun says: resolver team has to syncup & recap discussion with UX folks from earlier today, and see what's actionable right now. Zulip thread started to talk about one of those things. Will come up with more TODOs

• Invoicing
• May release of beta?
  • Sumana: feels unlikely, feels more like June to me
  • TP: yes, need some more time to do error messaging. but might want to release another alpha, and may improve many use cases already
  • Paul: TP is probably right. a lot more functionality has gone in since last alpha. We're not very far on error messages and that is a stumbling block. We also don't have any good sense of how bad the picture is on error messaging. Everyone may think it's ok now. Getting a second alpha out may give us a way to get more data. Some people have shown interest. Doug Hellman offers to test constraints. Functionality wise, we would be in good shape for a beta. But stuff around presentation, UX side of things, error messages in particular, where we struggle to get something out this month
  • Pradyun: we are basically there functionality wise, maybe just do the beta, then "tell us how you want this to be presented" push as part of beta cycle instead of trying to do it separately. Maybe utilize existing comms with them to get input. But as Paul said, if people say "it's good enough right now" vs "it's horrible now"... but we don't know. Pradyun feels: since we are mostly there functionality wise, and we are reaching out to users, doing more research, maybe just do beta. Maybe.
  • TODO: Sumana: start separate conversation about this.
  • Ilan: functionalitywise, new resolver works very well. I've added many more tests, including more realworld test where I create a repo with 130 packages and it solves also the difficult cases. which the old one did not do. It's optional anyway. It would also be ..... to only try out new feature with the special option ..... even in the beta ... is that correct

• Is implementing pubgrub/or similar algo in scope for the project? (changing the core resolver algorithm; from our meeting https://hackmd.io/el6WZNrTR-mK34szStCtrQ?both on Tuesday/Today)

  • Bernard: maybe Pradyun could explain?

  • P: in the discussions we had about error messaging: the direction we are heading is, essentially, rediscovering everything that was in PubGrub .... was in the tech choices we could make. We deferred on that by choosing the resolvlib API. Coming up in the error messages discussion. We're figuring out whether we should implement PubGrub. Pradyun says it is ok to not implement it right now, to meet deadline, but we should revisit it later.

  • Is it in scope for the project? I don't know. Sumana: want a good-enough resolver by end of year. if we decide that pubgrub is the only way to do this, then that's what we'll do -- based on technical judgement -- of if it's needed to reduce workarounds, better resolution, reduce technical debt, since we don't know if people can work on this later/after Dec 2020.

  • Paul: my big reservation: if we do that and then have to change the API we worked to, we would be gettting into a difficult situation - how much we end up reworking things and go backwards.... if we can implement PubGrub within resolvlib behind the scenes, then it's a drop-in replacement, great. if resolvlib api needs to change, then .... might risk taking too much time and effort.

  • Pradyun: if we are going in that direction, we will implement Python impementation of pubgrub using the resolvlib API
  • Paul: then this is something we can decide on .... it's a project management choice of where we want to invest the effort

  • TODO: Sumana to start conversation in Zulip -- done in GitHub https://github.com/pypa/pip/issues/8203 and will do in Zulip https://python.zulipchat.com/#narrow/stream/218659-pip-development/topic/PubGrub.20question (

    • Start reading Etherpad line 101 for detail: "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."
• Ilan adding tests: wants to add more real world tests with real package metadata. Then eventually testing the new error messages.
  • Pradyun: good thing for Ilan to work on next. Yes, add more real world tests with real package metadata.