PackagingWG/2020-03-26-pip

Legacy Wiki Page

This page was migrated from the old MoinMoin-based wiki. Information may be outdated or no longer applicable. For current documentation, see python.org.

Dev mini syncup

26 March 2020

Participants: Paul, Pradyun, Tzu-Ping

Agenda:

  • ignore_dependencies{.backtick} 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(){.backtick}

    • 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(){.backtick} implementation as well

  • Use installed dist: ignore_installed{.backtick} and force_reinstall{.backtick} 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{.backtick} again? (Probably not yet.)

    • We’ll talk about this priorities and upgrade_strategy{.backtick} 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__{.backtick} and __str__{.backtick} 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