Dev mini syncup

26 March 2020

Participants: Paul, Pradyun, Tzu-Ping

Agenda:

• ignore_dependencies implementation https://github.com/pypa/pip/pull/7888

  • It works!

  • Paul: wasn't expecting any issues. I'll catch up and merge; and deal with the merge conflicts.
  • TP: One of the problems is that we need to add/remove/modify arguments on the same function.
    • Paul: If we change that to partials, it'll simplify a bit. Avoiding too much coupling. Relatively simple to think about.
  • Pradyun: LGTM; one minor comment on set comparison.
    • TP: Can be a follow up PR.

• Extras implementation https://github.com/pypa/pip/pull/7897

  • Paul needs write the implementation idea down to avoid getting into the same loop every time.
  • Paul: code seems fine to me.
  • Invalid extras.
    • To warn undefined extras you need to know the list of defined extras
    • But to get a list of extras you need to prepare the dist, so we can’t warn as soon as we build the candidate
    • We can warn on get_dependencies(), but what if we call it multiple times
      • Cache the result (it’s not gonna change)
      • Pradyun: It’s still better to warn multiple times than not warning at all
    • Paul: Code currently doesn't have warning/logging mechanisms imported.

      • Paul: I'll put it in logger.warning()

  • A test on extra merging
    • Needed at some point, but not at the simple test case stage we’re in now
    • Paul: Expects Ilan will come in for this
    • Need to better understand how Ilan fits into the rest of the work here.

• Requires-Python prototype needs at least one interface tweak https://github.com/pypa/pip/pull/7889

  • Order of work: ignore_dependencies, extras, refactoring for decoupling, then this.

  • Need to change get_dependencies() implementation as well

• Use installed dist: ignore_installed and force_reinstall https://github.com/pypa/pip/projects/5#card-35032881

  • InstalledProjectCandidate

    • Refactoring of "make_candidate" will help.

      • InstallProjectCandidate would have a very different interface -- no links.

    • Again, it shouldn't be too difficult; but it's all prep work for the actual implementation.
    • Paul: treated with the right priority [inaudible]
    • Pradyun: Also need to think about how it fits in with priorities
    • Paul: Thinking about how to implement the flags, once we have a concrete candidate
    • TP: Agree with Paul; priorities is next topic!

• Is it time to talk about upgrade_strategy again? (Probably not yet.)

  • We'll talk about this priorities and upgrade_strategy later, once there is an implementation.

• Broader resolution debugging ideas!
  • visualizing the exploration?
  • E.g. resolver revisting a candidate when it shouldn’t, it would be easier to debug if we have a way to dump the state from the resolvelib side and then generate something to visualize that.
  • This is where reporter comes into play.
    • Pradyun: The problem of UI and debuggability are *very* close.
    • Paul: The reporter object should be able to do both (report things to the user, and dump state to the implementer)
    • Paul: Last time I needed to do something like this, I put prints in code.

    • TP: Where did you put the "print" -- that's probably a good place to report.

    • Paul: put them on the Provider.

    • Another useful thing would be to add better __repr__ and __str__ on our Requirement/Candidate objects

• Time's up! Team meeting time!

• TODO: Travis CI

  • BTW why is Travis stalling so much recently
    • :shrug: I don't know!

End of meeting.

Team syncup

Weekly team meeting March 26, 2020

Participants:

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

Agenda:

• Blockers
  • Pradyun:
    • nothing
    • almost done with documentation
  • Paul: I've got a few items I can work on; we have an order of work+PRs
    • Are we OK in terms of merging PRs, since TP can't merge changes?
    • How I can help: be more proactive in merging, if merge queue is a problem for TP.
  • Tzu-Ping:
    • not much of a problem that I can't merge. More like we need to decide when we want to merge things. Sometimes we are waiting for each other's opinion, but the back-and-forth causes a lot of overhead for a team setup like this.
    • Paul: maybe we have a list of ongoing PRs on syncup, or be more aggressive at merging.
    • Sumana: This sounds like a very rational case of wanting to not be rash. That sounds like something where a slightly more automated system would help. If we have a certain PRs in a milestone; having a tracking issue/project board to have a list of PRs in a particular place (waiting on approvals), are people hesitating is clicking approve?
    • TP: The flow of PR reviews -- responses to fixes by PR authors, after suggested changes are implemented.
    • Paul: Waiting on reviews from *everyone*, since we end up getting stuck waiting on people to review.
    • Sumana: Tracking your own, hasn't been merged yet. Pinging folks more eagerly. [too fast for note taker]

    • TODO: check in again next week, see whether that has helped

  • Georgia:
    • no blockers
    • Bernard and I were thinking about how to collaborate/knowledge-share more.
  • Bernard
    • no blockers.
    • The main issue is getting responses from people who said that they're interested in participating (part of the normal flow).
    • I can't do much user research without users to interview.
• Engaging people/users in intereviews

  • Sumana: "engagement funnel" -- how many people click "I'll be there" vs how many actually show up. I've publicized to improve this. PSF blog, PyPA twitter, LWN https://lwn.net/Articles/815902/ all have publicized about this.

  • Sumana: do we have number of how many people we want to interview to be "happy"?
  • Bernard: it's not going to be possible to have a number; given there are millions of users. 127 users right now, happy with these. 500 people by the end of the project, I would be over the moon. 250 people: more than happpy.
  • Sumana: I ask to prioritize the importance of trying to do user recruitment; if I have better sense of "gap" of where people are needed.
  • Bernard: It would be great to have the PSF twitter account to RT certain relevant tweets; on few more times/regular basis.
  • Bernard: Contacting podcasts. Having someone else who's a bit-more-recognizable do intros. (SH?)
  • Bernard: I don't want people to be doing this "full time" -- we're never guarenteed an ideal response.
  • Sumana: Ideal isn't possible; but we don't want to miss by an order of magnitude etc.

    • TODO: Sumana: get list of podcasts from Bernard, do intros

    • TODO: Sumana: get The PSF to tweet a few times per month for the rest of the project about the UX study signups

• Resolver team participating in UX calls
  • Sumana: [has this happened?]
  • Bernard: Has not happened, since there's been a blocker in scheduling calls.
  • Georgia: research infrastructure is in progress
• Suggestions on weekly collaborative working with the team

  • would get a lot out of collaboratively looking at issues that come into the GitHub queue ... have time to talk with people who are better at interpreting - technical issue? feedback needs changing? etc.

  • suggestion: 7:30-9am ET on Wednesdays... optional. Drop-in time.

    • https://www.worldtimebuddy.com/?pl=1&lid=2643743,1275339,5,1668341&h=1275339&date=4/1/2020%7C3

    • Paul: That's 11:30 am UK (maybe 10:30,we're changing to DST soon). I can maybe do some of that slot.
    • Tzu-Ping: 7am ET is not great for me .... could be free from 8am. Drop-in would work well for me.
    • Georgia - maybe 8-8:30, bug triage as a group
    • Paul: 7:30-9 slot is okay .... Wednesdays, I have other work commitments in the morning. Will try to drop in, may get pulled off. Will try next Wed.
  • Sumana: let's try it twice and see whether we need to reformat.
  • Bernard: Announce we want to do thing X at time T, and people can drop in if they can
    • Triage + Outreach + other things
    • SH: Triage is probably what this group being together would be best.
    • (discussion on potentially using Zoom) - we will use Zoom to start
    • SH: We should definitely have notes. Leave them in this or a different Etherpad, and then move them someplace more permanent.
• Ilan's involvement, testing

  • TODO: Sumana - follow up, get him in Zulip conversation

  • April - we will probably need to concentrate more on testing and test infrastructure

For the team, here's the type of participants who've signed up for research - how and why and where they use Python, etc. A taste!

http://www.ei8fdb.org/thoughts/2020/03/pip-ux-studies-response-data/

• Pradyun: looks great!

• (bernard) thanks

Additional TODO followups from the 19th:

• Sumana: start putting a due date on invoices
• Sumana: give Ernest a general summary of progress/project status

• Sumana: talk with Paul & Pradyun on Zulip to generate a list of names/teams/projects elsewhere in packaging, and invite them in small batches to some calls