Dev syncup, May 27th

Participants:

• Pradyun
• Paul
• Tzu-Ping

TODO:

• NULL
• Merge PRs
  • Another alpha after that?
    • Pradyun: Yea, I think so. Paul: I guess so. I don't have a problem with pushing the buttons. I wonder about comms though. Pradyun: Let's talk to Sumana today?
• New resolver on by default, in betas
  • Paul/Pradyun: no.
  • TP: the logic would be too confusing to explain.
• How far are we from the beta?
  • TP: Went through it on Monday, only 1 major thing left.
  • Paul: seems like it's doing the job on workloads.
    • We're in a state where it's releaseable as a beta.

• PreviousBuildDirError

  • https://github.com/pypa/pip/pull/8282 Merged (lol)

  • https://github.com/pypa/pip/pull/8283

  • Plan:
    • Merge the xfail test

    • Use the UUID route? Or TempDirectory

    • Try to deprecate --build

• Other stuff for next meeting (overflow)

  • --upgrade-strategy=never

    • https://github.com/pypa/pip/issues/4745

    • It's never going to leave us. \o/
  • Already Installed packages

    • https://github.com/pypa/pip/issues/7744

  • pip freeze showing "appdirs @ https://files.pythonhosted.org/packages/3b/00/2344469e2084fb287c2e0b57b72910309874c3245463acd6cf5e3db69324/appdirs-1.4.4-py2.py3-none-any.whl#sha256=a841dacd6b99318a741b166adb07e19ee71a274450e68237b4650ca1055ab128" with new resolver

    • TP: Likely due to PEP 610. Will need to review the logic after the wheel cache PR
  • That escape hatch for "let me do what I want"

    • https://github.com/pypa/pip/issues/8307

    • TP thinks this is out of scope
  • Requirements with (potentially conflicting) options

    • https://github.com/pypa/pip/issues/7846

Teamwide meeting, May 27th

Participants:

• Bernard
• Paul
• Nicole
• Pradyun
• Tzu-Ping
• Sumana
• Georgia (first half)
• Ilan (first half)
• Ernest

TODO:

• TODO - Ilan - ask that question on the PR -- do that today.

• TODO: phone call, TP & Ilan to get some notes to turn into the doc

• TODO: TP to set that up
• TODO: Sumana to work with Nicole on this idea for publicity: get PSF to ask its sponsors to do testing

• TODO: UX folks to start Zulip thread or GitHub issue if you want, so we can paste in code examples

• TODO: So - B & N: get that ticket in by the end of this week.

• TODO: Sumana: Are we ok to go to the Python community to ask "what if we had specific telemetry on package dependency conflicts?"
• TODO: Sumana: add "where to announce this" to docs

• TODO: Sumana to set up Thurs & Fri collaborative work times for 9-11am ET

Other followups from this & previous meetings:

• Sumana followup with TP and Paul about June
• TODO: Sumana: Are we ok to go to the Python community to ask "what if we had specific telemetry on package dependency conflicts?"
• TODO: Sumana: add "where to announce this" to docs

Agenda:

• Blockers/status
  • Pradyun: May 27th report for school (done!) VERY HAPPY TODAY :trumpets: :fireworks: :100:
    • Basically all done, needs to upload a few files and that's it.
    • Thinks he has no blockers. Still have a lot of chunks for the resolver team to work on
  • Ilan: been working some more on the testing of error messages in latest PR #8194 - now possible to add in case there is an error, what type of error code is expected, + part of the error message. For later discussion with the PR: not sure how specific the error messages should be tested. Could check for whole error message, but then if one word/phrase changes, it would break.
    • TODO - Ilan - ask that question on the PR -- do that today.
  • Bernard: all right [sigh]. Good day today. But we need more people to open tickets about trying to break the new resolver. So, doing something else in meantime

  • Georgia: am good. no blockers. been helping B & N with outreach, to try to get more folks testing & giving feedback on resolver

    • has been doing targeted outreach personally via email
    • Georgia can only stay until :30 past today. Still sorting out a conflicting meeting. Got it - Sumana

  • Nicole: is good generally. Like Bernard & Georgia, frustrated by lack of responses on ResolutionTooDeep. been doing personal outreach. Primary workplace, PeopleDoc, has a Python "tribe" - on Friday they have "Tribe day" to work on Python projects. Reached out to an organizer, will get some testing on pip this Friday. But many people said "I don't have conflict dependencies"

  • Tzu-Ping: figuring out what to do next - have work to do, will be fine for a while. Lots of rain.

    • PyCon Taiwan: current plan: optimistic about a physical event in the autumn. But will also let people join online probably; online streaming. TP has concerns about complexity

  • Paul: difficulties this week. blocker: getting in new resolvlib release -- preliminaries: making sure of getting PRs merged in a timely way. waiting: not on anything.
  • Sumana: [redacted]

• Ilan's testing work & wrapping it up

  • PR #8194 is current work
  • has now worked a total of 54 hours. have 16 hours left.
    • possible to finish those up by the end of May.

    • how long will it take to finish this PR? Depends on feedback, & how detailed the error message should be?

      • if not very detailed: maybe a few hours....
      • if very detailed: maybe 10 hours
      • if adding some more documentation: a couple hours
    • TP wants a writeup about how YAML tests work. Some documentation would be great.

      • TODO: phone call, TP & Ilan to get some notes to turn into the doc

      • TODO: TP to set that up

• UX output & followup on [redacted: Notion document by Simply Secure]

  • getting more reports re: resolutiontoodeep & resolution impossible:

    • TODO: Sumana to work with Nicole on this idea for publicity: get PSF to ask its sponsors to do testing
    • Today is May 27th.
    • What if we gave ourselves a week (3rd June), to try and push and get more reports. If we don't, then we'll do something else, and move forward with whatever we have.

    • B, N, & G had a discussion about this: even without data, we do have best practices re: providing info to user. We've started a draft of some error messages for ResolutionImpossible (not yet ResolutionTooDeep). There's a Notion page

      • https://www.notion.so/simplysecure/WIP-Example-error-messages-7b4ede077ad54c10a8f4182795fb949d -- see "where a user wants to install packages (with 1 or more pinned version)" and (to come) "Example best error messages for resolution:too-deep"

        • Mention what the user has tried to do
        • possible next steps to try to solve the error
        • order those suggestions from easiest to most complicated
        • give some context re why the error has happened and how the user can try to find out more about this
      • Paul: this is much more verbose than we are USED to seeing out of pip. May not be a bad thing!
      • Bernard: # of words, formatting, etc. can be changed.
      • Paul: it makes sense to me. do not have a problem with it. Not sure yet whether the info is yet available to implement it at the time of the error. .... we would need to address some things to make this possible.

      • Nicole: aspirational.

      • Paul: as a principle it's fine.
      • TP: we need to structure this in a way that the user can understand it -- ..... inexperienced users often have problems reading long stuff. "just tell me what to do" ... past a length threshold, may lead to them just posting to issue trackers
      • Nicole: "long error messages" - tracebacks .... this is different to a traceback error
      • Bernard: reason for not reading: I don't knwo what it means, it takes knowledge I don't have, it takes a lot of work. they are looking for next steps to solve the problem. so we put in steps to solve diff problems because pip is not able to tell user what the issue exactly is and tell the user exactly what to do.... we are trying to give user, from easiest to most complicated next-step solution.... this is our first version. totally open to be ripped apart, critiqued.
      • Paul: with that in mind: I get that this is a principle. But, looking at possible solutions mentioned there, not sure that, in my experience, if I saw this, I don't think any of those suggestions would be pracically something someone could do..... like replacing it with a diff package altogether, or patching it, or .... they don't feel like things people will be able to do .... the prob I have is, I don't have any better suggestions would be..... but these are not things I would say on the issue tracker. I like giving a list of possible suggesed solutions. devil will be in working out what the suggestions are ......
      • Sumana: but these are suggestions that come from UX research
      • Paul: what if the suggestions were more dynamically generated and not just quarterly updated
      • Pradyun:
        • Pradyun thinks it would be better to put the list of possible solutions in docs, additional context
          • Sumana: but what about the length concern?
          • The way Rust handles error messages

      • TODO: UX folks to start Zulip thread (or GitHub issue if you want), so we can paste in code examples

  • output auditing
    • Nicole has been doing this. Pradyun gave a list of all different messages pip outputs. Now in a spreadsheet. There are ~183 in total.

    • Next: Nicole to look at those. column in spreadsheet: context & meaning of this message.

    • wil prioritize ... info logging level first (that's what gets shown by default, right?)

      • info, warning, and debug, right? are the 3 logging levels? in that order? -v, -vv, -vvv

      • info and warning are shown by default, info is yellow. debug is only shown if you choose more verbosity
    • plan: try to get as far as possible without dev time, but will probably ask Paul for SOME time to understand those, double-check understanding
  • after that: a glossary of terms
    • there are concerns about, e.g., "build" in terms for output for user
    • style guide!!!!!!! Sumana and Pradyun are excited!
    • start of one for Python packaging in general? but there are conficts in what different projects call things
    • we have a Warehouse glossary that we could use as a jumping-off point
    • would be helpful for Milestone 3 (doc overhaul) and for helping new contributors write more docs
    • Sumana says yay
• collaborative work sessions for Sumana

  • this week: Thurs & Fri morning -- will set up some videocalls for 9am-11am ET

• next deliverable -- a "please test this" push in June? [how far are we?]
  • Pradyun: we're almost there in terms of technical stuff. 1 edge case left. Some either not or very complicated stuff that will come up via beta
  • we are basically good to go in terms of pip impementation ......
  • 2 areas where we are blocked

    • rollout & comms would look like - people got confsed with the beta that we just released. let's not have that happen again

    • output stuff -- is this output relevant to users? is it not relevant? too many lines of output .....
  • Paul: agrees
  • TP: agrees
  • Nicole: would prefer to put out better error messages in beta so we can get user feedback in beta and improve those. rahter than putting out something at the end. may not be recived how we want it to be

  • Paul: it's been hard to get traction on the proposal in a "we can code this" way.... what if suggestions of message improvements turned into GitHub tickets:

    • when you do A,B, C, we want the output to look like THIS
  • Sumana: agrees

  • Bernard: in https://www.notion.so/WIP-Example-error-messages-7b4ede077ad54c10a8f4182795fb949d -- we've broken the error messages into 2 resolution exceptions. 1 is Res Impossible, the other is Res Too Deep

    • Is this breakdown the right way to do it?

    • Paul: slightly different -- if you put that in a ticket, I would be saying (normally) pip install peach=1.0 apple=2.0 are not real projects. Give me a reproducible concrete example.

    • I would then have questions, e.g., "what is pip-search"

  • Bernard: to replicate ResolutionImpossible, by trying to install 2+ packages where I have specified a version, pinned a version of 1 of them: is that couched enough?

    • Paul needs an executable command line
  • for Paul: Ticket would say "in this example, we get this error, we want this other one instead"

  • Bernard: Will all ResolutionImpossible exceptions be caused by same type of installation request?

    • Paul: we don't know. practically: pick one, we'll fix that, and then we'll notice as we fix and test.
  • Nicole: good way of approaching it. challenge to find the concrete use cases. good way for us to bridge comms gap

    • Q: is there something N & B need to be able to create those bug reports? a template? way to repesent those tests so we can run them?

      • we don't know yet. N can let you know on Zulip, once we know what we need
  • Sequence is: In the next week, we will try to get out publicity to get user reports of resolution errors.
  • And we will work via bug reports on improving message output based on the principles we already know.
  • next week - on Wed Jun 3rd, try to come up with a date for the beta (hopefully early June)

  • Sumana: OK with wordier messages helping people to have an idea what to do. Better to get something out & polish

  • Nicole: if we are on a tight timescale, .... may not have time to flesh out docs in time for beta

  • Nicole asks: when do developers need the GitHub tickets in order to meet that req?

    • fundamental question - can we track what is causing the conflict and that's something we have been thinking of ... we have been waiting on new version of resolvelib that'll give more information .... that's the big blocker on that. That's the version TP is now integrating into pip. trying to get that merged today or tomorrow.....
    • checking how and when we can get that into an error message, so, a bug report will make that so much easier

    • TODO: So - B & N: get that ticket in by the end of this week.

      • OK. Can get 5-6. by tomorrow.