Dev mini syncup chat

9 April 2020

Participants: Paul, Pradyun, Tzu-Ping

Not much to talk about because we discussed everything yesterday

Pradyun improved the CI, the whole suite is now in 17-ish minutes

Why is extra a marker (10 minutes of random conversation)

Team meeting

Resolver group syncup 9 April 2020 Participants:

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

Agenda:

• Invoices
  • TODO: Sumana to send Ilan PDF version of sample invoice
    • please include due date
  • [Ernest notes re: schedules of payments for payouts]
• Followups:
  • Paul on release note (see line 154 currently)
    • TODO: Sumana to check in tomorrow - give stern look if necessary on coding some reporting stuff
  • Sumana on summarizing "what goes in the April release?", getting other maintainers to talk with us about timeline
    • TODO - get help from Bernard and/or Pradyun on that, coworking after this call?
  • TODO: Sumana: hour? video? for regular call?
• Blockers/ waiting on from other people:
  • [general discussion of the PRs awaiting review; pending reviews are generally because others don't have quite enough time to review, but there isn't a huge ongoing blockage]
  • Tzu-Ping: I think I'm waiting on Pradyun to take a look at few PRs.
    • For Bernard: Conversation with research participant - idea for a new pip command that binds? versions. Needs participant's contact info
      • TODO: Bernard to give TP the user's contact info
  • Pradyun: nothing!
    • [discussion on PR reviews]
  • Paul: nothing... main thing blocking him is more .... HIMSELF....... [dun dun dun!!!]
    • deep philosophy. should we report? how to report? was stalled earlier.
    • Bernard offers: if any of that is UX-related, "should we report this or not," happy to have a chat about it, including coming up with the question.
    • on pending reviews: agrees with others. some things get stalled.
      • On getting other maintainers (Xavier, Jerdonek, Donald) to review -- let's try, but it can be harder to ping them (e.g. on Zulip)
      • Pradyun: difference in speed/philosophy/pace. Speed of current work is faster than usual feedback cycle.
        • TODO: closer to release date: let's revisit that.
  • Bernard: nothing except knowledge of pip.
    • Sumana: some coworking sessions will help
  • Ilan: I had a good discussion with Pradyun on Saturday and I worked on a new PR that has now been merged. I then saw in Zulip last night that Paul had requested a few things. That's on Ilan's TODO list. Not blocked by anything right now.
  • Sumana: waiting for Bernard, list of podcasts
    • TODO: Bernard to find them for her
• Installed Packages causing conflicts (UX inputs would be great)
  • This is tricky to explain concisely. In cases of dep conflicts with already-installed packages, we want to understand user expectations of what good behavior would be, what they expect, what would be easy to reason about.
  • This discussion is stuck - help, Bernard!
  • Install dependencies is DIFFERENT from build dependencies.
    • Example scenario: user has package A installed, depending on a certain version of B. User asks to install C, which depends on a diff version of package B. When you install C, what to do about B?
      • can't - if you do, you will break A
      • "you can do this but need to upgrade A to do this". Did user want us to upgrade A? ok for us to do that?
      • Or! To install C: you can do this but might need to DOWNGRADE package A to be ok with a compat version of package B.
      • Maybe fiddling with version of B is ok with the remit we have been given. But to what extent? what options do we have about package A? Are we allowed to leave things broken? to upgrade A? to downgrade A? what makes sense?
      • We do not know what makes sense.
      • We all have some ideas of how it should be. Some are not aligned. How do we pick options?
    • Paul did a little UX checking on his own. Explained situation to son, and immediate reaction was "make this an error". But when we started asking: what if user then wants to make a decision? how many options to present? then degenerated to a hard question.
  • TODO: Bernard: follow up after call.
    • May be worth sending a question to the ~200 people who have signed up for research
  • Having AN answer to this problem is a blocker to us having a testable beta
    • Bernard will guarantee that we will get an as-sensible-as-possible answer by the time of the beta

• Ilan & testing

  • Pradyun: not much to add to what Ilan said
  • there's work that we've decided needs doing in an approximate sequence. No unexpected surprises yet
  • Ilan's work does not directly depend on Pradyun's CI improvements
  • TODO: Ilan has some questions to Paul -- Ilan saw comment last night in Zulip re: YAML tests
    • Paul says: yes, please go ahead and ping on Zulip. We can have a call if necessary
• pip output messages - how closely do we have to match current? (UX inputs would be great)
  • Paul says: not that big a deal, but: some tests are flagging up cases where the new resolver reports something different from existing resolver's reports. Not sure - considering how to present resolver's results to the user. How closely do we need to match what is already there? Instinct: approx is good enough. But! We have to play games with the tests to make them pass. Would prefer avoiding skipping arbitrary tests, or saying "with old resolver we expect foo output, with new, bar".

  • Past Pradyun wanted to redo the entire output, partly because of this problem. https://github.com/pypa/pip/issues/4649

    • Bernard: why is the new resolver reporting different than old?
      • Simple example: "pip install foo" which does not exist. Old one says: no such thing. New one: collects all dependencies; "can't find anything that matches whole dependency set". It thinks in sets rather than one at a time. We can work around this, but, tricky heuristics "if user requested 1.... 2...."
      • If user is trying to do same thing, old vs new, as closely as possible, match current resolver in this (consistency), where it makes sense

      • TODO: further conversation between Paul & Bernard, feat. M.C. Pradyun

      • Useful faq: https://www.youtube.com/watch?v=B6-45rswo0o (how to beatbox like a pro)

      • TP: a discussion from the other day: we agree that we don't quite know what to do.
• pip CI revamping update!
  • Pradyun: a work update: spent the last few days making it faster, better, easier to reason about pip's CI setup. Has reached a good state. Had Paul look a bit earlier today. We're headed in the right direction! Starting to break this pile of work into reviewable PRs! Yay!
    • Sumana: yay!
• re: installed packages / upgrade strategy -- Ilan might have inputs since he probably has dealt with this issue in conda.
  • TP: kind of a consummation of the installed packages question. Same conversation: question of how we do upgrades. pip has 2 upgrade modes: "eager" and "only if needed". We're not sure what we should do for which ..... we want to ask Ilan: how does conda do upgrades?

    • Ilan: conda has only 1 upgrade mode. For the longest time, conda did not take which packages were installed into consideration. "install this package" - look at dep tree, and install those packages. Anything already installed would be left alone (if it was already matching on version) or it would upgrade or downgrade that. Then: that changed (not Ilan's preference). It took into consideration all the things already installed, and made resolver much more complicated & slower. But I think that was a poor move. It's best to keep things simple. I never had a problem with the original way conda's upgrade strategy worked.

    • Paul: what motivated the change?
    • Ilan: under old strategy: some existing packages can break. Example: A depends on B, you install C which depends on another version of B, so you might break A. But I think that is a rare use case and not worth making a huge change.
    • Sumana: did you have data on it being a rare use case?
    • Ilan: no; we had only download data on packages. No user studies. Just some people that thought this behavior was incorrect and we should make it so conda always does the right thing.
    • Sumana: how much slower did it make the resolver?
    • Ilan: depending on use case: was hard to tell where the resolver was spending all its time, incl in envs with 50-100 packages. What would often happen: resolver works for a very long time, and people file reports that "it's been running for an hour now and I still don't ... doesn't want to install anything". And in conda you can easily create a new env. So people often would just create a new env with the packages they want. And new env means you don't have that prob, because you don't look at all the exitsing packages.
    • Paul: do you have any way of getting an example of something that triggered that kind of behavior in the conda resolver, so we can use it to make a pip performance test to ensure we don't hit the same problem?
    • Ilan: I was no longer involved with conda at that point. This was a case people in the wild experienced when they had a lot of packages, awkward environment situation. Issues were in public bug tracker. I can find some
    • TODO: Ilan to give a pointer to an issue tracker item
  • TP: What happens in current version of conda if it wants to, for example, A depends on B, B wants a different version of C than is installed? If the env will break no matter what and there is no solution?
    • Ilan: conda tells you: can't do that. Prints a very long and not-easy-to-understand error message. It will try to tell you what the conflicts are. Will not install it.