Log file Viewer
#pypa-dev logs for Saturday the 31st of March, 2018
[00:37:28] <thea> okay, dstufft, di_codes, release PR merged. If y'all want you can add me on PyPI or you can publish yourselves. :) Thanks for all the help today.
[00:41:47] <dstufft> thea: you're now in the critical path for a non trivial number of users, so don't ruin their day ;)
[00:49:02] <techalchemy> dstufft: is there a pypa appveyor account we should be building on similar to travis? I'm not sure if that gets us more things or whatever
[00:50:02] <techalchemy> ok, wasn't sure if there are extra features or anything like that we are missing out on
[03:28:17] <njs> techalchemy: IIRC appveyor is annoying and doesn't actually have a concept of "group account"
[03:29:46] <techalchemy> njs: okay, that's unfortunate, i was just hoping for parallel builds or something cuz it's so slow
[03:30:39] <njs> techalchemy: ah, that's maybe a slightly different issue -- I was thinking of the thing where appveyor believes every project belongs to exactly one person (who might also give other people permissions on it)
[03:31:16] <techalchemy> well I was technically just hoping that if we could get pipenv under the pypa the pypa would have special features :p
[03:32:19] <njs> it looks like doubling appveyor concurrency would be $500/year, or for "unlimited concurrency" would be $1500/year
[03:33:30] <njs> or someone could try emailing them and begging, yeah :-) I feel like I've seen other projects try this but I don't remember if it worked
[03:34:58] <njs> oh I mis-read, the "unlimited concurrency" one is on-premise, which might be more hassle than anyone wants. weird that they don't have a hosted option for more than 2 concurrent builds.
[03:35:42] <techalchemy> I may not understand how detox works correctly but I was thinking it might be possible to have multiple concurrent 'builds' running as virtualenvs in the same build
[03:36:30] <techalchemy> but yeah i dont think anyone wants to manage a whole suite of ci infrastructure
[03:36:43] <njs> oh they hide it in the fine print -- for the hosted version it's basically $300/year per concurrent job (for open-source projects)
[03:44:06] <techalchemy> we could possibly get donated virtual server space somewhere and spin up some other ci, but I don't know enough to offer a useful alternative
[03:46:49] <njs> that will cost an order of magnitude more than $300/year if you price people's time anywhere appropriately
[05:05:04] <techalchemy> njs: true, but considering it's often the main resource we have available in open source it's the one i'm accustomed to spending :p
[11:13:56] <pf_moore> sumanah: Hi, thanks - I hadn't realised it needed approval, yes if you could that would be great.
[11:15:21] <pf_moore> sumanah: Towncrier - it's an automated step that I just ran. I've not done it before.
[11:16:03] <sumanah> pf_moore: I had a semver-related issue with a similar thing in Twine's CHANGELOG
[11:16:25] <sumanah> where I had to mark some bugfixes as "major" to make them show up for a .0 feature release
[11:16:54] <pf_moore> sumanah: Yeah, tbh I don't even know where towncrier gets that release number from. Probably a step that needs adding to the docs.
[11:17:20] <sumanah> pf_moore: so right now this is a list whose listinfo says it is "A low-traffic, announce-only list to announce major changes to the Python Package Index, legacy http://pypi.python.org/ or new http://pypi.org/ ."
[11:18:16] <pf_moore> sumanah: Yeah, I wondered about that. When it was pypa-announce it was the "obvious" place to do pip announcements. I probably should have asked before sending what the new policy was.
[11:18:23] <sumanah> if we were to say, what is the absolute minimum set of stuff this list should be about -- this is related to https://github.com/python/psf-infra-meta/issues/1 -- then ..... right
[11:18:39] <sumanah> pf_moore: as far as I can tell no one ever sent anything to pypa-announce -- did I miss something there?
[11:19:38] <pf_moore> sumanah: possibly not. Yeah likely timing, plus maybe a bit of "we'd forgotten it existed until you suggested renaming it"!!!
[11:20:22] <sumanah> I have been making a twine one https://twine.readthedocs.io/en/latest/contributing.html#making-a-new-release
[11:20:24] <pf_moore> sumanah: There's a section in the docs: https://pip.pypa.io/en/latest/development/#release-process
[11:21:27] <sumanah> pf_moore: so let's say, probably setting up some kind of "packaging tools announce" list or discovering an existing one would be a good thing
[11:21:55] <sumanah> pf_moore: how about I file that in https://github.com/python/psf-infra-meta/issues
[11:22:08] <pf_moore> sumanah: This is the first time in ages anyone other than dstufft has done a release, so there's probably a few things in his head, or specific to his PC :-) Also I'm on Windows, so fixing the odd Unix-ism at the last minute was fun...
[11:22:20] <sumanah> pf_moore: and that way when you get pip 10.0.0 out, in the pypi-announce mail, we can point people to that other list for future announcements
[11:23:02] <pf_moore> Sounds like a good idea. I'm hoping we can get a better release pace on pip, in future, so getting things like this thrashed out would help a lot
[11:23:22] <sumanah> pf_moore: is there any other existing announce list you want to post to for this? I know you have access to post to https://blog.python.org/ which propagates several places
[11:24:38] <pf_moore> I've posted to distutils-sig, python-list and python-announce, all of which seem to have gone through. I'll put the post on blog.python.org as well, and then I think I'm done.
[11:27:49] <sumanah> pf_moore: and https://github.com/python/psf-infra-meta/issues/1 has a few more suggestions if you want to really signal-boost stuff
[11:51:41] <sumanah> pf_moore: https://github.com/python/psf-infra-meta/issues/1#issuecomment-377687595 decided to add this to the existing issue
[15:15:31] <dstufft> pf_moore: sorry was asleep! I see you had a few bumps, but it looks like everything went okayish :)
[15:23:43] <dstufft> pf_moore: https://github.com/pypa/pip/pull/5129 should fix towncrier, I made a note there that I wouldn't rerun towncrier as part of release 10.0.0, I'd just manually updates NEWS.rst to change 10.0.0b1 to 10.0.0
[15:28:33] <pf_moore> dstufft: Thanks, yeah that looks right to me too. My main problem at the time was that it was the first time I'd ever run towncrier, so I wasn't really sure how it worked...
[15:32:39] <dstufft> pf_moore: but yea, the beta release makes this a little different, but ultimately the process will be the same as what I would have done, the release/X branch will just last longer before you bump it to 10.0.0 and submit a PR to merge it into master
[15:34:27] <pf_moore> dstufft: OK yeah, that makes much more sense. I'll make it clearer in the docs so that it's recorded for future. Also I'll add some notes on what to check and where to publicise releases, and some administrative things like that.
[15:36:51] <pf_moore> dstufft: Yeah, the shell only uses double quote. My quick hack was to simply switch the quotes, but I don't really like the outer quotes being single quotes, so I may revisit that. Cosmetic changes can probably wait till after the bank holiday weekend though - I'm gonna take some time to relax with the family!
[15:37:06] <techalchemy> dstufft: I may have asked this already, but what is the timeline for pip10?
[15:38:22] <pf_moore> High techalchemy. Yeah, final release (assuming no showstoppers) weekend of 14/15 Apr. See https://blog.python.org/2018/03/beta-release-of-pip-version-10.html
[15:39:36] <techalchemy> pf_moore: we just addressed a similar quoting issue -- I wound up backporting shlex.quote for 2.7 and shlex.split(posix=False) to swap the quotes
[15:40:30] <pf_moore> techalchemy: Hopefully I win't have to go that far, this one's just a static command. But yeah, quoting's fun...
[15:42:11] <dstufft> we don't really have to care about broad compatability with them, only pip maintainers will ever run them
[15:43:01] <pf_moore> dstufft: Ha, you say that to the guy who fixed all the Windows compatibility issues :-) Gotta keep you Unix guys honest somehow!
[15:45:20] <pf_moore> dstufft: Yeah, we're slowly removing all the excuses for everyone to dump all the work on you ;-)
[15:45:33] <dstufft> (I actually did try to make them Windows compatible, I just had no idea that the quote I used mattered)
[15:49:47] <pf_moore> techalchemy: I don't know that we do much. Not really my area, but AFAIR we try to not break things for them when they unvendor everything and that's mostly it
[15:50:40] <pf_moore> There seem to be a fair number of bugs that go by related to Debian weirdnesses, but we tend to point them at Debian in the first place, so I don't know how much that counts :-)
[15:55:32] <dstufft> techalchemy: FWIW it may not make as much sense for pipenv to bundle, IIRC pipenv gets installed outside of the venv that it's managing right?
[15:56:34] <dstufft> techalchemy: https://github.com/pypa/pip/tree/master/src/pip/_vendor#rationale has our rationale, and I don't use pipenv soI could be wrong about how it works, but I *think* these don't apply there.
[16:03:00] <pf_moore> techalchemy: Looking at that issue, it occurs to me that installing pipenv in its own environment via a tool like pipsi might avoid the need to vendor. That's how I install pipenv, and it works for my (limited) use. But it does mean users have to choose between buying into a tool like pipsi or hitting dependency management issues.
[16:09:53] <techalchemy> dstufft: it can get installed outside or inside, the vendoring calls have been made (when I've been the one making them anyway) based on whether I need to pin a version that might conflict with system dependencies
[16:11:25] <techalchemy> pf_moore: that would definitely be true => we have a lot of moving parts and likely have some things we could unvendor (at this point we likely have some vendored code we aren't even using)
[16:12:26] <dstufft> techalchemy: Yea, ofc it's up to the pipenv project how it manages it's deps, I just know from experience it tends to be painful to deal with downstream when you vendor. It took us a long time to get them to believe us :)
[16:14:00] <techalchemy> dstufft: that aligns with my understanding, I'll try to tag in Nick or Nate or someone who can say more words at them
[19:39:04] <agronholm> di_codes: on another note, any insights into this? https://github.com/pypa/wheel/issues/117
[22:13:04] <sumanah_> pf_moore: I see you have the power to email "python-announce-list" which I did not know about till just now :) could I ask you to forward the PyPI beta announcement email there?
[22:32:27] <sumanah> anowlcalledjosh: btw will you be at PyCon North America or EuroPython this year?
[22:50:43] <njs> pf_moore: btw for the pip 10 final announcement, I think it'd be nice to go into a little more detail about the changes for those who aren't insiders? Like the description of pyproject.toml could mention that it's a replacement for setup_requires= that works?
[22:51:44] <njs> pf_moore: something I've seen other folks do is to put a draft of this kind of announcement in a pastebin or something to get a quick round of feedback before posting -- might be worth considering now that pypa actually has people around and paying attention :-)
[22:55:16] <techalchemy> personally (though I don't know if this has been tracked during development) I'd be interested in any documents tracking internal API changes
[22:56:00] <sumanah> techalchemy: ok. I was under the impression that pip makes zero promises about the dependability of internal pip APIs but maybe I am misunderstanding
[22:57:14] <sumanah> techalchemy: kind of like the Architecture of Open Source Software architecture walkthroughs
[22:58:09] <sumanah> techalchemy: btw who from pipenv is coming to PyCon North America this year, and will any of y'all be sprinting? I want to make https://wiki.python.org/psf/PackagingSprints reasonably comprehensive
[22:58:38] <techalchemy> when we invariably start trying to move from pip9 to pip10 though it would be nice to have a cheatsheet :p
[23:07:36] <techalchemy> sumanah: I can let you know for sure this week, remind me if I don't get back to you
[23:07:58] <sumanah> techalchemy: I'm just going to set a calendar reminder, same as you would :) but ok
[23:09:42] <techalchemy> sumanah: I'm not that organized, I tend to dismiss any reminder that isn't an actual meeting