11 May

Participants:

• Paul
• Pradyun
• TP

Agenda:

- Pradyun is happy that someone else closed the meeting notes like he's been doing for so long! (with [syntax])

- UX + Pradyun syncups!

• Circular dependency figured out
• UX team + Ilan will collect test cases
• Main problem now:
  • What metrics to use for the “too complicated” error?
  • TP: Maximum versions tried per package, sounds perfect!
    • Everyone agrees. Paul: Doesn't sound like it'd be too difficult in resolvelib.
  • Paul: When we do the finder logic in the provider, there's never any reason we'd return 2 compatible ones.

    • will ask on Zulip, since this is a bigger topic that might not need much discussion or need lots of discussion.

- PubGrub:

• TP: Was reading PubGrub before this call. Current takeaway is that Python specifiers is missing -- negation: Django > 3.0 to Django <= 3.0. We'd need to implement negation (non trivial!)

• TP: Implementing incompatibility tracking would be better; since it's significantly faster.

• TP: Does not make sense to switch to PubGrub now (Python packaging logic lacks negation, which is essential for PubGrub)

- What are we working on next?

• Paul: Couple/Three of things
  • Tidying up anything that comes out of the constraints issue (2 failing tests that TP found)

    • As long as it works for OpenStack, what we should do is remove those tests, and declare that constraints aren't meant to do that anyway.

    • Will add / improve documentation.

      • Only valid as "project <= version" and similar forms.

      • Pradyun: Validation?
        • Paul: Don't want to get side-tracked by that entire discussion -- will do if it's easy. Will come back with "let's not bother" if it's hard.
  • Documentation of update mode (reminded by an issue mention/notification)
    • Will have another pass.
    • Wanna get some writeup that talks about what we do. The longer I take, the more annoyed at this situation.
    • Wanna be less annoyed at how complicated it is!
  • Refactoring Requirements-bit, so that they're on the provider instead.

    • It also makes sense to move upgrade_strategy.

    • Have the factory be responsible for get the candidates from Finder.
    • Provider puts them in the correct order.
    • All ordering logic in Provider. All internal-interaction with Factory.
      • Pradyun: we should document this structure is being taken.

      • TP: since we need to rewrite find_matches, I was planning on adding a new class for it -- your plan sounds equally good.

      • Paul: This is where the question about more-than-one-candidate-per-question.
    • Particularly, when it's doing the matching by versions etc in the sorting.
    • It might be easier if the factory to return 1 candidate per version.
    • [Pradyun (note taker) got distracted/zoned out]
    • Paul: That sounds like what we wanna do.
• TP:
  • Yanked

    • depends on https://github.com/pypa/pip/pull/8066

  • find_matches() rewrite

    • Might conflict with Paul's planned refactor.
    • Paul: Tell me to stop, if there's conflicts.
    • TP: I will likely be introducing a new class.
  • TP: need to look at the tests.
  • Pradyun: we should look at all the issues, and write down something about this.
    • Paul: would be really nice.
    • TP: I tried doing that -- I got stuck on the constraints
    • [we talk about how we get stuck while doing this -- it's horrible or I can try this (few minutes later) this is horrible]
    • while we're looking at the tests, it would be nice to finally thrash out how "old resolver test" vs "new resolver" tests should work.
      • might be check the environment.

      • Add a --new-resolver option in pytest and check that throughout the suite

        • interaction with YAML tests
• Pradyun
  • Actually triage issues (lol)
    • Did a bit last week, but had to walk away after getting frustrated with the in-place builds responses (and landing on #5599).
  • Get 20.1.1 out.
    • Reverting in-place-builds.
      • PR
      • Paul: we've got to do it, because of the issues.
        • We've had a couple of people who've come in and say "this is cool!"
        • Should give a heads up to those people.
        • Reopen issues, telling people why we had to do the revert.
        • Paul to do this on one issue. Pradyun will copy-paste on others, after reverting.
  • Wrap up visualization stuff
    • Put it in a library / tool, instead of a bunch of file in my local resolvelib.
  • Look at the failures
    • Note down what's happening here.
    • Need to put a clock or something, to keep me from digging too deep.

  • Look into the .[extras] (stretch goal)

  • TP: I'd be very impressed if you make it past the first 2 bullets this week.
  • Paul: Yea, that's a lot of stuff.

• Constraints -- covered above