PackagingWG/2020-04-02-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

2 April 2020

Participants: Paul, Pradyun, Tzu-Ping

  • Agenda

    • Why is Travis so flaky? Nobody (literally) knows

    • work done?

    • pipeline of work:

      • debuggabilty

        • Paul: added hooks to the reporter.

        • TP: We’d probably want to print when the resolver backtracks.

        • Visualisation on the dependency tree

      • Look at the test suite, and see what’s failing what’s not

      • TP: We’ll need to discuss the upgrade strategy stuff.

      • WheelCache

      • DependencyCache

    • What do we want to put the resolver in a reasonable state for the April release for users to play with

      • Reasonable state: after adding “python-requires” should be pretty good.

      • Paul: Add candidate priority calculation and a release note about how stuff works

      • TP: Error out on not-supported options

Team meeting

Team syncup

2 April 2020

Participants:

  • Bernard

  • Paul

  • Pradyun

  • Sumana

  • Tzu-Ping

  • Georgia

  • Ilan

Agenda

  • How is everyone

    • Let’s keep not being a part of the “numbers” being published :)

  • Invoices

    • Invoices this week would help PSF. Make sure to include a due date.

    • Atos: believes the invoice has been sent.

    • Ilan: question about invoices

      • TODO: Sumana to follow up personally - DONE

  • It’s release month!

    • Pradyun: let’s discuss: what do we want in the release?

      • What will actually get in?

        • To discuss: unstable resolver feature

          • It’s in master now. So, yes.

        • Messaging about functionality ….

          • Do we want to tell people about it? at all?

            • Bernard: blog post talking about the resolver says it will be released in ~May. So we’ve told people that … maybe stick to that?

            • Paul: we do have a documented release schedule where we release in Jan, April, July, October. We probably ought to stick to that.

            • Sumana thoughts: we promised an alpha or a beta in May. So we can say the April feature is “pre-alpha, do not use” and then in May do an alpha or beta.

            • Pradyun: do we want point releases or beta releases where people have to do –pre?

            • Paul: if we do it as a point release, any changes in master that aren’t resolver-related ….. doing that with live releases might be disruptive …. re bugfixes. So, let’s make the extra releases be pre-releases (marked as such PEP 400), so resolver-unrelated bugfixes are not disrupted. But we do not have a prerelease process as such ….. So, for expediency, 20.1.1 might be EASIER…. pros and cons. The non-resolver work that happens on master

            • TP: feels similar to Paul. A pre-release would be a better idea, but we don’t have a way to do that right now.

            • Sumana: we would have to invest in developing that …. other maintainers might be able to help

            • Pradyun: wouldn’t take a lot of effort IMO. There’s a GitHub issue asking for beta release process or similar [to link]

            • Paul: pip 10 betas were not that painful, but we did them manually. If it’s not too hard to automate, maybe best to do that

            • TODO: Sumana to summarize on issue, then get other maintainers to opine

            • Issue on prerelease automation https://github.com/pypa/pip/issues/7952

        • release notes

      • What should the timeline of the release be? We usually like to have it in the first half of the month

  • Teaming up with Sumana on organizing the project board

  • Ilan and testing stuff

    • Pradyun: did onboarding with Ilan last week. He’s started working on stuff - PRs to change small things. He’s geting a feel for codebase, YAML tests – <200 lines, but lots of interacting with other parts of test suite

    • Ilan: yes. Looked at test suite, wrapped head around it, and yesterday added a feature to add option for “no dependency” during test (?) …. latest PR. Not really for merging yet. Just a way to make my work visible, other features might go into that PR as well…. other features & refactoring I am doing. I have a good feel for what is going on now.

    • Pradyun: during the call on the 28th (Ilan and Pradyun), discussed features to implement in YAML tests, specifically: getting checks for error messages, being able to select and skip tests based on the resolver they run with. Getting close on those first would be high priority IMO.

    • Paul: Agree. Sounds like a good starting point. Don’t want to make a big shopping list; rather be prioritized. Will say, though: documenting how someone else should add in a YAML test to try out a particular scenario. Might be straightforward, but: if I write a feature, how do I write a YAML test that exercises that feature & proves it works? Use the fact that Ilan was just up that learning curve.

      • After that: just start writing a bunch of tests

      • But Pradyun’s comment was best first step, probably

    • TP: in terms of prioritizing, Pradyun’s suggestion is good. But also Ilan can look at the current new resolver tests to get an idea of what other features would be needed in YAML test – but Pradyun can also get that info himself

    • Ilan: reading the tests of the new resolver ….. today …. running the YAML resolver tests with the new resolver – didn’t quite work yet. So … want to fix ….. see why it’s not working.

      • TP: Oh he has already done what I wanted! :-)

    • Ilan and Pradyun to continue liaising with each other

      • have another call in the next few days

    • TODO: Ilan: tell Sumana every time you spend 10 hours

      • So far, he has spent about 14 hours