== 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