Log file Viewer
#pypa-dev logs for Monday the 20th of April, 2020
[14:27:46] <bhrutledge> Hi folks. It's been awhile. In lieu of PyCon sprints, I'm spending the day tending to Twine. My current priority is coming up with a roadmap to enable other contributors to add missing type annotations, based on the work I started in https://github.com/pypa/twine/issues/231.
[14:29:12] <sumanah> for people who don't know: in early 2018 and then some in 2019 I worked on Twine a lot, and then last year at the PyCon sprints I helped Brian get started with Twine
[14:30:35] <bhrutledge> Hi sumanah! My pleasure. Out of curiosity, does this group have preferred tools for screensharing?
[14:31:19] <sumanah> bhrutledge: no preferred tools as far as I know. I have used Whereby, and Google Meet, and (ugh) Zoom... I am curious about asciicinema
[14:32:40] <sumanah> bhrutledge: if you would like to work on a document while simultaneously videochatting, we could use the video Etherpad installation they've set up
[14:33:13] <bhrutledge> My sense is that last asciinema is handy for asynchronous terminal recordings. I'm thinking more in terms of live code review, using my editor (VS Code) and/or the GitHub UI.
[14:34:05] <bhrutledge> Though I'm curious what "video Etherpad installation" means. But that could also be later.
[14:36:09] <sumanah> bhrutledge: ok! so I'd be happy to give some input, in conversation and/or on a document
[14:36:56] <sumanah> right now I am sorting out a couple of things -- working with pradyunsg and other folks on some release notes and related informational documents for the April pip release, and working with techalchemy on the Pipenv release
[14:37:24] <sumanah> bhrutledge: sangy is a PhD candidate working on cybersecurity at NYU - one of the people interested in better securing the Python package supply chain
[14:38:22] <sumanah> sangy: Friday the 24th? Hope I can virtually attend! :-) and let me know if you need a guinea pig to watch a practice version
[14:39:11] <sangy> thank you! Yeah I think I should do a practice run or two with some live audience. It feels a little packed as until friday I was working on the actual thesis
[14:39:15] <sumanah> bhrutledge: so you wanna just talk things out here a bit, regarding what needs to happen for the type annotation work, and we'll figure out the sequence?
[14:40:34] <sumanah> pipenv release issue: https://github.com/pypa/pipenv/issues/3369 .... pip https://github.com/pypa/pip/issues/7951
[14:52:48] <sumanah> bhrutledge: for reference: https://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/
[15:19:24] <sumanah> alanbato: How is the https://discuss.python.org/t/feature-proposal-for-pypi-draft-releases/3903/4 discussion going in your opinion?
[15:19:44] <sumanah> (everybody: I'm working on https://github.com/pypa/pip/issues/7951 at the moment so I may be a bit delayed in replying here - please mention my nickname to get my attention)
[15:25:10] <sumanah> also alanbato I changed the title of https://github.com/pypa/warehouse/issues/726 to "Draft release feature on main archive to allow testing a release before it goes live" to better reflect the feature
[15:39:16] <alanbato> sumanah: I'm happy people are showing interest and asking important questions regarding the implementation. I'm even happier that people with more experience and context are answering some of those questions too.
[15:39:45] <alanbato> I think creating such a thread was a _very_ good idea. I wouldn't want having this discussion inside a PR review haha, it'd be more costly.
[15:41:27] <alanbato> Since the discussion is kind of long now, and there's some points where a consensus has been made and others that it hasn't, I wanted to make a summary so people can have a good understanding of the situation a week later.
[15:42:42] <alanbato> It would basically say: "We will be doing this, not that. We want it to look like this, behave like that" for things that we are strongly opinionated about. And then some "We are still unsure if we should do X or Y" for the other points
[15:43:18] <alanbato> Have you had a chance to follow the discussion? I'd like your opinion on it too
[15:43:51] <sumanah> (also di_codes is https://github.com/pypa/warehouse/pull/5838 the PR about yanked releases ready for re-review?)
[15:45:03] <sumanah> alanbato: in case you hadn't already been thinking about it: in my opinion it is important to post a comment listing the open questions where it feels like you don't have a consensus/answer yet
[15:45:37] <sumanah> I skimmed it alanbato - please nudge me later this week so I can take a deeper look?
[15:46:27] <alanbato> Yes, I'll make clear what questions remain open. And sure, I'll ping you later this week
[16:42:00] <devesh> Re: mypy type annotations, I tried out your instructions using MonkeyType, they work really well in adding types to twine submodules
[17:10:44] <PSFSlack1> <di> And yeah, that yanked release PR is ready for re-review, probably by dstufft
[17:44:47] <PSFSlack1> <deveshkusingh> Hi sumanah: Hope you are doing good. I have start looking at twine, and have submitted some PRs wrt adding unit tests
[17:47:24] <sumanah> Glad those suggestions have been helpful, devesh. Did you take any of my other suggestions?
[17:56:12] <sumanah> (there was a blip just now so if anyone tried to private message "sumanah" for about the past 2 min, it didn't get through)
[17:57:28] <devesh> Almost all my queries were able to be answered by my own research, or via github
[17:59:34] <devesh> Yes, I have been going through their issues and trying to pick something to start with.
[18:00:00] <sumanah> devesh: what are the criteria you use to decide whether to ping/@-mention someone in GitHub?
[18:04:23] <devesh> Ideally I should do it sparingly, because I came to know that almost all updates on the PRs/issues do go to the commiters
[18:04:57] <sumanah> yes, sparingly, that's right, so: what are your criteria devesh? More specific criteria will help you here
[18:05:36] <devesh> I mean the only reason I can think now if there is a old issue i would want to work on, to get the poster's attention
[18:06:12] <sumanah> devesh: even then, note that usually the original poster is subscribed to the issue, so you don't need to @-mention them.
[18:06:36] <sumanah> devesh: let's also talk about cadence, rhythm, timing, etc. regarding posting comments in GitHub at all
[18:09:06] <sumanah> if you're asking for an update on a bug or a pull request then you should explain _why_ you are asking for an update, and show that you have already done as much as you can without getting new info from other people
[18:09:55] <sumanah> if you are asking for an update just because you generally want to know whether anyone has new info on the issue, then you have a poor reason for asking for other people to do work
[18:10:32] <sumanah> a better reason would be "I am going to work on this and here is the work-in-progress branch I have so far"
[18:11:12] <devesh> Instead of say "I would like to work on this. I have these ideas I can" , actually show them the work in a PR?
[18:12:39] <devesh> but then I think I need to be a better judge of "If this is something too trivial to work at, so it's better to be sure first after asking in a comment?"
[18:12:41] <sumanah> Filtering criteria like "do I need to get a response on this in order to meet a deadline someone else is expecting of me?" or "is the lack of a response on this stopping me from getting or doing something I need" (note: NEED, not want)
[18:13:01] <sumanah> could you rephrase? not sure I understand what you mean about "too trivial to work at"
[18:13:46] <devesh> So for e.g. there is an issue for a feature request, and the commiters have already suggested workaround for that request which seem good enough
[18:14:24] <devesh> like, say in context with pip, adding a new argument to a command, which can be easily achieved by adding a filter like sed or grep to an existing command
[18:15:15] <devesh> Do I go ahead and still create a WIP branch, or do I just say, hey this is a good alternative instead of adding another feature, maybe I can try it out
[18:15:51] <sumanah> I figure you go ahead and create a WIP branch and link to it in a comment in the thread
[18:15:59] <devesh> Yes, I assume when you say "wasting" work, that means working on things which can be achieved by other alternatives,
[18:16:57] <sumanah> It seems to me like you have a lot of capacity to work, more than most of the people you are trying to collaborate with on the project
[18:17:21] <sumanah> you are not going to be able to optimize and only write code for features that everyone wants
[18:18:04] <sumanah> and go ahead and write work-in-progress code for stuff that you are interested in, that you think would be a good idea, and then link to your WIP branch in a comment if/when you get stuck
[18:18:50] <sumanah> sometimes it will turn out that other people don't want that feature, and that the process of talking with you about your code will be the spur the maintainers need to resolve the issue as "no, we do not want this feature"
[18:18:54] <devesh> Okay, but does that make one a good open source collaborator, not keeping up with the pace of development and seem like too much demanding
[18:20:16] <devesh> I was going through brett cannon's blog on "Setting expectations for open source participation"
[18:20:29] <sumanah> also, I'm trying to give you advice right now that will help you be a better contributor to pip. The advice for another open source project might be different and I recommend you read VM Brasseur's book for more general advice
[18:20:56] <sumanah> ok I'm rereading https://snarky.ca/setting-expectations-for-open-source-participation/ now
[18:22:09] <devesh> Primarily point 7, "Typical scenarios in open source" and how do I follow them in my interaction with maintainers at pip
[18:23:05] <devesh> And yes, I understand your advice about pip in specific, but given your background with OSS in general, I think it's good advice with FOSS in general
[18:23:59] <dstufft> to sumanah's point, as an OSS maintainer, I am way more likely to bother to engage someone who has brought at least an attempt at solving the problem even if it's incomplete and lacking tests, etc and maybe it doesn't even fully work yet. because I have a decade+ experience of people coming in, asking a bunch of questions about how to achieve something, and then disappearing never to be seen again. There's some leeway to that, if you're about to
[18:24:00] <dstufft> undertake a massive rewrite or massive new feature than it's probably better to get some buy in before putting pen to paper (but also you probably don't want to start out with some massive new feature to start with either)
[18:24:53] <devesh> My aim in the end is to be a good contributor with pip and build a lasting relation, so I should make a point to have good interactions with maintainers in general
[18:26:41] <sumanah> dstufft: physically we're all right. mentally: today I'm sad, tired, behind on work, everything feels cluttered and hard
[18:27:30] <devesh> thanks dstufft for your point, I do see quite a few issues/features which were made in pip, but then abandoned, I was planning to work on them to learn more about pip
[18:28:45] <dstufft> I guess an interesting thing to know maybe is that I probably get 2-5k emails a week? I never really measured it but it feels like that's about what it comes to if I hide from my email for any signifcant period of time
[18:29:07] <sumanah> devesh: ok, glad you have a way forward now. And you mentioned "the pace of development" -- a reason I keep mentioning Spack to you is that I think their pace IS A BETTER MATCH FOR YOU than pip's pace
[18:29:19] <devesh> Hi sumanah: Please take care, I guess you have explained me a good bit on how to get traction with issues
[18:29:48] <dstufft> So when I'm scanning through my email looking for stuff to poke at, I tend to look for things that have the most actionable content
[18:31:03] <devesh> sumanah: So the pace is not a bad thing then, I thought it was, but the pace should match the response time. I will likely focus efforts there too in near future
[18:32:06] <devesh> and put more effort in actually coding up something, which will make it a better learning for my own that asking an approach in a comment
[18:32:15] <sumanah> I don't understand what you mean devesh when you say "So the pace is not a bad thing then, I thought it was,"
[18:33:35] <devesh> I mean wrt to pip, trying to create PRs and then commenting on them frequently to ask for updates regularly
[18:33:39] <sumanah> but anyway I agree that coding up work-in-progress, and then (if necessary) asking for feedback on it, is a better approach than only asking about an approach in a comment (without demonstrating in code)
[18:34:13] <sumanah> CORRECT: with pip, go ahead and create PRs, but "commenting on them frequently to ask for updates regularly" is annoying and gives you a bad reputation
[18:35:12] <devesh> Agreed, if you want to grow from a contributor to a maintainer some day, you should be good with such things, and not build a bad name for yourself
[19:29:38] <travis-ci> Change view : https://github.com/pypa/pip/compare/03d3ae01ac04...7722cf05569d
[20:20:54] <bhrutledge> I've made some progress on type annotations. Still hoping to have a PR up today.
[20:21:25] <sumanah> I can talk now a bit about product management in PyPA's suite if you want bhrutledge
[20:22:23] <bhrutledge> Thanks, but I'm inclined to keep a narrower focus today, assuming we can talk another time.
[20:39:07] <PSFSlack1> <deveshkusingh> And thanks for the detailed feedback and help in the initial PRs. Much appreciated
[20:44:17] <sumanah> also, dstufft I would appreciate your reply on https://groups.google.com/forum/#!topic/pypa-dev/twf9HCGfv3k "archive this group & redirect conversation elsewhere?"
[22:38:21] <techalchemy> i can't even guess how many hours i've wasted debugging azure failures which seem to pop up for no reason at all now