Log file Viewer
#pypa-dev logs for Wednesday the 16th of May, 2018
[16:10:31] <toad_polo> I really don't like the idea that we're having a reply-all backchannel discussion about something important. We can always blow away the mailing list if we decide to reorganize the comms structure.
[16:15:24] <dstufft> jaraco: might make sense to try to use https://botbot.me/ if pmxbot is having issues
[16:15:55] <dstufft> cooperlees: toad_polo I just woke up, getting a ML is just sending an email to postmaster, I can do that here in a minute
[16:16:16] <cooperlees> Mark Saporo is who Barry said. I can walk around to the Mailman hack and ask him if we all agree we want it
[16:17:21] <toad_polo> Better to have it even if all we use it for is deciding we don't need it and it gets thrown into archive only mode.
[16:18:53] <di_codes> any opposition to making it pypa-committers instead of pypa-core? that’s a bit more explicit about who should be on the list
[16:19:35] <dstufft> either naming is fine, doesn't really matter too much, committers matches python's naming so seems reasonable
[16:39:10] <sumanah> The PyCon 2018 sprint on packaging/distro has moved from room 26B to room 20 at the convention center
[16:44:57] <cooperlees> Mark said to email him. I will after lunch and cc you at dstufft ... message me your email toad_polo and I’ll cc you too
[16:46:05] <honzakral> EWDurbin: I realized one more thing that I cannot find - we should be setting number of replicas to 2 for elasticsearch (since there are 3 data nodes), not sure it's the case in production as it's part of the environment
[17:01:16] <di_codes> honzakral: it looks like it’s currently being pulled from the ELASTICSEARCH_URL envvar: <https://github.com/pypa/warehouse/blob/master/warehouse/search/__init__.py#L39-L53>
[17:08:57] <honzakral> di_codes: thanks fo rchecking. If replicas are set to 1 we are wasting one node and also don't have as much HA as we could
[17:25:30] <dstufft> honzakral: di_codes yea, EWDurbin will have to fetch the value for that then, he's th eonly one who can pull protected envvars out of vault atm
[18:44:15] <jaraco> @pradyunsg or dstufft: tomfbiz could use some feedback on https://github.com/pypa/pip/issues/3905 . Mainly do we want this change and in what contexts. Can you or someone advise?
[18:46:05] <pradyunsg> jaraco: While you're around, would you be looking into the IRC-Gitter bridge any time soon?
[18:50:15] <jaraco> @pradyunsg I’m not interested in creating a bridge between IRC and Gitter. I see there’s a service for that (https://sameroom.io/blog/how-to-bridge-existing-irc-channels-and-rooms-on-gitter/), but since Gitter provides an IRC interface, my preference would be to move the communities rather than maintain resources to bridge them.
[18:50:51] <dstufft> seems like it'd be fine to just remove the gobal/virtualenv nonsense and just store a single cache file in the cache directory
[18:51:19] <jaraco> I’m also happy to stay on IRC or with Gitter or even maintain the status quo. My Gitter experience is better, but last I inquired here, there wasn’t much interest in moving to Gitter.
[18:52:36] <dstufft> jaraco: pradyunsg probably I'd warn against making any sort of communication changes until the governance+communication question gets shaked out, unlikely we're going to mandate a particular platform for project specific stuff, but in general it'd be nice to have as much stuff on the same platform as possible.
[18:52:54] <jaraco> It does seem there’s revived interest in Gitter (I saw some interest on the summit ether pad to move pypa and pypa-dev to Gitter).
[18:53:49] <pradyunsg> jaraco: I'd written that point for discussion and I wasn't at the summit so idk if that was discussed. :P
[18:53:52] <jaraco> Echoing what dstufft says, I agree; let’s settle on something and consolidate. Please loop me in if there’s a forum where the comms discussion is progressing; otherwise, my positions are represented above.
[18:54:16] <tomfbiz> I'm wondering if someone has a different version of pip in their venv, it might be useful to have the two locations. But if you are overriding in the pip.conf, I assume that would override regardless?
[18:54:36] <dstufft> jaraco: Yea, I think there's basic sentiment on first solving the question of how do we make decisions (aka governance) and then move onto "how do we communicate"
[18:55:38] <dstufft> jaraco: so whatever the outcome of governance is, that's wher ei twill happen, likely on the pypa-committers ML once that's created (at least temporarily if not permantely)
[18:56:27] <pradyunsg> dstufft: agreed that let's figure out governance -> let's figure out comms is likely a good way for this.
[18:57:03] <dstufft> (kind of amusing that PyPA started out as a joke for pip/virtualenv's github org, and then somehow became a real thing)
[18:57:09] <tomfbiz> dstuff -- Should we make a separate ticket to remove the two locations for the lock, which maybe should be addressed before the over-ride ticket?
[18:57:35] <dstufft> tomfbiz: I think it's fine to do it together, or if you want to do them seperately (or only want to do one or the other) splitting them up is OK too
[18:57:43] <tomfbiz> dstufft -- Should we make a separate ticket to remove the two locations for the lock, which maybe should be addressed before the over-ride ticket?
[18:58:36] <dstufft> I don't think the changes are going to be huge or controversial so either I'm personally happy with
[18:58:45] <dstufft> (and since I think we're hitting some CI limitations right now, combining is attractive ;) )
[18:59:22] <pradyunsg> di_codes: I think you were going to contact Travis about the CI issues? What'd they say?
[18:59:43] <cooperlees> I liked warehouse's IRC hours - I think the collective PyPA should do that too every month or something like that
[19:02:09] <pradyunsg> dstufft: what do you mean by "PyPA started out as a joke for pip/virtualenv's github org"? I'm curious. :P
[19:02:49] <cooperlees> I'm happy to own keeping meetings and setting agenda and canceling if there is nothing to raise.
[19:03:58] <tomfbiz> dstufft -- I'm curious -- what is this pip version number used for? Are certain packages only installable by specific versions of pip?
[19:04:17] <di_codes> who was the person chatting with us when the fastly/GCP issues were affecting pypi/travis
[19:04:35] <dstufft> pradyunsg: so this predates me, so my info is mostly 2nd hand, but from what I gather, when pip and virtualenv were moving to github they were moving off of ianb's personal bitbucket accounts, and so they needed an org name to own them, since it was two tools a name like pip/virtualenv and pip/pip didn't make much sense, so someone suggested the Python Packaging Authority as a joke, because at the time pip/virtualenv were very much the new
[19:05:27] <di_codes> ironically if that person hadn’t suggested the pypa org, we wouldn’t be having CI issues this week
[19:06:36] <dstufft> cooperlees: Yea i certainly think it'd be cool as long as we kept the frequency tuned to the right level so that it's not a burden, but also not so far apart that they're useless. I don't want to throw a roadblock, but potentionally might make sense to wait for the comms stuff to get sorted out too, but I don't think it _needs_ to if you want to socialize the idea amongst the other pypa folks (a decent list is in the email I sent!)
[19:07:02] <pradyunsg> tomfbiz: see https://github.com/pypa/pip/blob/master/src/pip/_internal/utils/outdated.py#L109-L120
[19:12:06] <pradyunsg> dstufft: it seems that pip's cache behaves in an incompatible manner in Py2 vs Py3 now. Do you have any pointers as to where to start looking?
[19:19:15] <dstufft> I've briefly considered the idea of auto-locking all closed issues older than N amount of time
[19:26:37] <dstufft> pradyunsg: also I think it'll mean less things remain open when thy shouldn't, since we're super bad at closing them :)
[19:33:34] <jonathan2> Hi, seems like if you query `curl -v https://pypi.org/pypi/bogus/1.0.0/json` with an illegitimate package/version combination, you get into an infinite 301 loop. This seems to be new behavior as of today (I noticed it because license_finder gem going haywire on internal packages which aren't in PyPi)
[19:41:33] <pradyunsg> di_codes: I just unwatched the warehouse repo (lots of notifications) -- feel free to give me a mention if I could be helpful somewhere. :)
[19:57:34] <dstufft> zulip and discourse seem like they might be a good replacement for irc and mailing lists
[19:58:38] <techalchemy> i didn't really see how to use it i guess, it seemed a lot less intuitive than the competitors
[20:00:36] <dstufft> (ultimately the question of what will get shaken out of course!) I haven't really used zulip much so I'm still getting used to it
[20:02:55] <pradyunsg> I've said this before but no harm in restating -- I'm familiar with Discourse and it would probably fit our working model well.
[22:23:26] <tomfbiz> dstufft -- I created a PR https://github.com/pypa/pip/pull/5419 I will be at Pycon sprints tomorrow morning. Please let me know if you need any additional tests for this, or any other changes needed.
[22:24:52] <cooperlees> Any pip people around to look / discuss adding --json to `pip download` (Don't know what this IRC client did there)
[23:03:16] <mbacchi> di_codes: I looked into the personal access token I was using for the github API. There actually is a way to setup a 'machine user' which is a GitHub account you could create with read only access to the repository, and use that key in the api query: https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users
[23:06:14] <mbacchi> di_codes: But i also did a query without my personal access token and the query to get all the contributor statistics only reduced my query quota by 1, so a single query request should be fine while unauthenticated. I'll work on that shortly.
[23:26:45] <mbacchi> di_codes: I lied. I thought I was making 1 query to the github api for contributor info. But I actually make (1 + warehouse contributor count) to get info on each contributor, which is currently over the rate limit of 60 requests per hour. Either I'd have to write the task to perform partial steps every hour unauthenticated, or use an access key which gives us up to 5000 requests per hour.
[23:29:44] <mbacchi> s/steps every hour unauthenticated/steps over a series of hours unauthenticated/