Log file Viewer
#pypa-dev logs for Thursday the 13th of June, 2019
[01:30:00] <sumanah> pradyunsg: is there anything we the pip & packaging community can do to help you get more work done faster on the resolver?
[01:32:10] <sumanah> [and in case any of y'all are wondering what I'm listening to while pecking away in emacs, it's Guster's new album "Look Alive" which has a ska track that I love]
[01:42:10] <sumanah> pradyunsg: I'd love for you to reflect on and share that. Maybe part of what you need is other people pitching in more to triage pip bugs and review pip PRs. Maybe part of what you need is other people testing your work in progress. Maybe we could help by providing rubber duck time :)
[01:44:52] <pradyunsg> Actually, right now, inputs on https://github.com/pypa/pip/issues/6536 would probably help me figure out how to approach the work / get feedback from people etc.
[01:48:19] <sumanah> pradyunsg: hey could you help me understand - https://github.com/pradyunsg/zazo and https://github.com/sarugaku/resolvelib - how are these different?
[01:51:17] <pradyunsg> The only difference is that resolvelib is a bit more fleshed out and has a DAG implemented. They're both built independently, modelling the problem in the same way, and at the same abstraction level.
[01:54:32] <pradyunsg> The two packages are basically the same -- Dan/TP (pipenv maintainers) and me will likely just go with whichever we end up picking in pip.
[01:55:23] <sumanah> pradyunsg: I presume we would want to move one of them under the PyPA umbrella at that point?
[01:58:22] <sumanah> you should probably also make a note about it in https://github.com/pypa/pip/issues/5051
[02:00:43] <sumanah> pradyunsg: re: New Resolver: Rollout, Feedback Loops and Development Flow #6536 -- the input you want is something like: is the feature flag approach a good idea? is it a good idea to get feedback via some mechanism other than the pip GitHub issues? is it a good idea to get a grant or similar to get realworld manual testing & robust testing infrastructure built, and/or proactive comms?
[02:06:10] <pradyunsg> Yep -- whether the ideas I'm suggesting are good. Also any additional ideas/approaches/thoughts that might help the rollout + feedback be smoother would be awesome.
[02:19:23] <pradyunsg> sumanah: Do you have any advice on how to communicate on https://github.com/pypa/pip/pull/6596?
[02:26:12] <sumanah> like "Thank you for this PR. I am planning on reviewing and merging it. While you wait for me to do that, which should take me a day or two, I think it would be great if you could also start looking at #nnnn. If you think it's something you could start working on, leave a comment saying so, and then please start working on it"
[02:26:47] <sumanah> pradyunsg: feel free to save some of these bits of verbiage as "saved replies" in GitHub which will save you time retyping
[02:35:53] <techalchemy> also like, resolver rollout stuff is just incredibly hard. I can help with that but i am so overwhelmed
[02:37:09] <techalchemy> if you can link me to the azure build you are looking at with a lot of checks i might be able to help
[02:37:41] <techalchemy> i'm @ a canonical hosted event right now trying to build images with snapcraft
[02:38:39] <pradyunsg> reg Azure - I just want to not see 29 checks on our PRs. A PR is linked to in a comment before the one you're mentioned in.
[02:41:15] <techalchemy> i can try to make a pip snap for you if you want, i have no clue if it will work
[03:10:24] <toad_polo> techalchemy: At the packaging summit the resolver turned out to be a blocker for or step one of a lot of the things we wanted to achieve.
[03:10:52] <toad_polo> Not sure if that's the reason for the urgency, but it's a good reason to prioritize it.
[03:13:35] <techalchemy> toad_polo: not saying it shouldn't be prioritized, i was just confused about sumanah's interest
[03:14:35] <toad_polo> techalchemy: I think Ernest tweeted all the notes we took, and Sumana has been following up. I'm not sure I could come up with the list off the top of my head.
[03:15:21] <techalchemy> well with regard to moving the project into the pypa, i have asaked multiple people many times to clarify who can move things into the pypa and when and i always get vague answers
[03:17:15] <toad_polo> I'm sure Ernest or Donald can do it, maybe Dustin too, if you just mean who has admin on the org.
[03:18:04] <toad_polo> I think deciding what projects belong in the pypa may be a consensus process? The governance discussion is intended to help sort that out I think.
[03:24:25] <pradyunsg> IMO moving projects to PyPA is basically, letting folks know that you want to do it and, if no one has any major concerns, doing it. The lack of actual process here is basically the PyPA Governance discussion.
[03:24:55] <techalchemy> i see a lot of hand waving about how things are independent and everyone can do what they want but i mean, I personally don't feel comfortable moving things into the pypa / still feel like an outsider mostly and i think other people can and do, so I see why those people are happy not talking about how things work
[03:26:00] <techalchemy> how do you establish if nobody has concerns, or even if the project is a good candidate to be in the pypa umbrella
[03:26:38] <pradyunsg> My approach to the 'pypa' organization is -- if we're gonna add it to packaging.python.org or it's an underlying tool for multiple projects already in the organization.
[03:26:58] <techalchemy> i mean you're just leading me to the same kinds of question about each successive point
[03:28:36] <pradyunsg> Something like resolvelib? Yea. Something like pip-shims? Probably not because of a conflicting message vs pip's "don't use our internals".
[03:31:02] <pradyunsg> Basically, if the underlying library/tool is something like 'packaging' that is used by other PyPA projects, we can put it in the organization. If it's something that's going to be noted down on at packaging.python.org, we can put it in the organization. The rest of the cases, are a lot more in the air IMO.
[03:35:59] <pradyunsg> tbh, I really think we should trim the list of packages in the PyPA organization (things like 'history' and 'scripttest' don't really belong there IMO)
[03:36:02] <njs> techalchemy: (a) the lack of process is a bug we need to fix, (b) in the mean time the traditional way this gets solved is that people just do stuff without asking for permission and it mostly works out (and the people who don't have the confidence to do that get driven away, see point (a))
[03:36:41] <njs> techalchemy: if it makes you feel better you could do a post like "hey I think this should move into pypa, I'm gonna do it one week from now unless someone tells me not to"
[03:37:08] <njs> and everyone will be like "oh yay someone is actually doing something and I don't have to get involved, what a lovely gift techalchemy has given me" :-)
[18:40:06] <sumanah> hi techalchemy -- are you around for a few minutes? I read the logs at http://kafka.dcpython.org/day/pypa-dev/2019-06-13 and wanted to clear a thing or two up with you
[18:40:57] <sumanah> techalchemy: ok. so from your perspective, me asking "how can we help you get this done faster" seems like sudden urgency?
[18:41:20] <techalchemy> well it was more the trying to figure out how to get everything else out of the way
[18:42:07] <techalchemy> seemed like it is therefore the highest priority item which i didn't follow i guess
[18:42:28] <sumanah> techalchemy: I'm not sure that you realize that the phrasing you're using makes it sound like you think the previous state of affairs, in terms of pip's momentum, was the preferred rate of progress
[18:44:42] <sumanah> techalchemy: If you have a specific thing you think that we should prioritize (in pip development) over progress on the resolver, I am genuinely open to hearing that
[18:50:45] <sumanah> I'm basing my understanding on the notes from the packaging minisummit (discussion of extras storage, of increasing metadata strictness), conversations with conda folks, last year's minisummit, a bunch of bugs/features that seem to block on pip's dependency resolver....
[18:51:38] <techalchemy> sumanah: no i don't follow pip's issue tracker, i was literally surprised about the prioritization
[18:53:09] <sumanah> pradyunsg has been making gradual progress on a project that has turned out to be incredibly knotty, and has a lot of demands on his time as a pip maintainer; it stands to reason that one way to help him make progress on the gnarly thing is to get other people to help on the other things
[18:55:38] <sumanah> is this urgent? well, it's important. And perhaps I feel urgency because I foresee potential things that could happen if we don't help Pradyun finish this sooner rather than later. To be super morbid, what if something happens to his health?
[19:00:20] <sumanah> techalchemy: I'm totally fine with learning that I am wrong and that there's some other thing I should be directing my energies to unblocking. But growing new pip bug triagers, building better test infrastructure to make it easier to test the new resolver, and building better communications to get systematic testing of new packaging features seem like they'll be pretty helpful even if the resolver only turns out to be priority #3
[19:01:46] <sumanah> and the specific timing of me asking about this stuff is: it's been a few weeks since the packaging minisummit and, as part of my contract with the PSF to help with PyPA coordination/communications, I'm helping nudge along the TODOs from that meeting
[19:03:11] <sumanah> techalchemy: thanks for engaging with me on this -- I appreciate your perspective
[19:05:01] <sumanah> ofek[m]: if you have a little time to help work on it, IMO the best way to help in the short term might be to help review open pip PRs, to take some of the load off Pradyun -- in the longer term we would love help building some test infrastructure