Log file Viewer
#pypa-dev logs for Saturday the 30th of May, 2020
[01:34:44] <sumanah> di_codes: I think https://github.com/pypa/pypi-legacy/issues/789 should just be directly transferred over to the support ticket queue, based on the linked issues
[02:40:24] <sumanah> dstufft: yeah you might want to go to your SourceForge notification settings and turn off support request emails
[02:40:31] <dstufft> sumanah: yea lol it's no problem forgot you were going to do ti a second and got really confused why I had a hundred emails from SF lmao
[03:18:52] <sumanah> ok, down to 137 issues, gonna call it a night, take on more sometime in the next few days
[08:24:51] <travis-ci> Change view : https://github.com/pypa/pip/compare/0521e112274f...c348c4215bf8
[08:59:22] <McSinyx[m]> the pro argument is for experimental features, it's easier for willing users to test
[09:00:15] <McSinyx[m]> the con argument is that it's not clear how often is often enough (every pass build? every experimental feature's bug fix?)
[09:03:13] <travis-ci> Change view : https://github.com/pypa/pip/compare/c348c4215bf8...7ed5e12ae83e
[10:22:29] <pradyunsg> McSinyx[m]: probably not -- I think an improved pre-release process is much more important than more frequent pre-releases. Changes to that process (especially the ones that sumanah has suggested -- proper communication channels, setting up a community of users who'd do these tests etc) would likely be much more effective tools.
[10:23:15] <pradyunsg> For now, we're working with what we have at hand, and we'll use this experience to see what approach would fit best (taking into account the limited developer time we have as well). :)
[10:28:54] <PSFSlack> <deveshkusingh> FWIW, a release schedule of 3 months, with a few beta releases a week or two before is a good release plan
[10:30:00] <PSFSlack> <deveshkusingh> That's a good enough time duration for some improvements to move in pip, and not too frequent for consumers to update the pinned versions
[10:59:48] <pradyunsg> @deveshkusingh: a week/two weeks might not be a long enough time for a good feedback cycle, but I do think that there's not much sense in doing anything beyond a beta period prior to the main releases.
[11:04:02] <PSFSlack> <deveshkusingh> pradyunsg: I agree with that. Beta can be used for downstream distributors of pip, like linux distros to get a taste of what's about to come, and provide any breaking changes that might need fixing before teh main release
[11:12:46] <pradyunsg> @deveshkusingh: and anyone else who wants experimental stuff, can just use the master branch, if they really want the bleeding edge. 🤷
[11:14:42] <PSFSlack> <deveshkusingh> I think they can also use the `devX` version as well right? Does that perform the same as using `pip install git+https://github.com/pypa/pip.git#egg=master` ?
[11:16:59] <PSFSlack> <deveshkusingh> But I don't see an easy way for a developer to know that `20.2.dev1` is the bleeding edge/dev version in the docs
[11:19:05] <McSinyx[m]> I'm not sure if IIUC but I think dev* is by convention the bleeding edge version
[11:19:48] <McSinyx[m]> and by the forum/discourse posts the UX teams are encouraging people to try out pip --pre
[11:20:46] <PSFSlack> <deveshkusingh> Aah so, `pip install -U pip --pre` will automatically download the latest dev version?
[11:21:42] <McSinyx[m]> the latest prerelease version I think, e.g. we can't go dev for the next 2 months because there's already beta
[11:24:22] <pradyunsg> @deveshkusingh: again, what's the benefit of giving people easier access to the bleeding edge?
[11:25:28] <pradyunsg> And how does: run `pip install https://github.com/pypa/pip/archive/master.zip` not satisfy that use case?
[11:26:14] <pradyunsg> It's not just about whether we can do it, but more about what's the benefit of doing it.
[11:26:30] <PSFSlack> <deveshkusingh> I think you are asking re: But I don't see an easy way for a developer to know that `20.2.dev1` is the bleeding edge/dev version in the docs
[11:27:54] <PSFSlack> <deveshkusingh> Yes I think the `pip install https://github.com/pypa/pip/archive/master.zip` should be enough for it
[11:28:22] <PSFSlack> <deveshkusingh> In that this makes it clear to the user that you are installing from the latest master branch
[11:33:03] <PSFSlack> <deveshkusingh> But is it worth documenting that specific command in the docs? I currently can't find it.
[11:33:31] <PSFSlack> <deveshkusingh> If we document it, we can ask a user to say verify a fix for a bug we fixed by pointing him to that doc, and asking him to try it out
[11:33:59] <McSinyx[m]> I think the benefit of hand-crafted release vs master is that we have human to decide when it the good time
[11:35:15] <McSinyx[m]> but that'll cause a human to spend time doing it and taking responsibility on it, so maintainers will have to cut time on development to do such thing
[11:36:15] <PSFSlack> <deveshkusingh> I think we have tools like nox to automate a lot of those steps.
[12:07:09] <travis-ci> Change view : https://github.com/pypa/pip/compare/7ed5e12ae83e...d01bfcfaa13a
[14:49:49] <bhrutledge> Can someone explain (or point me to an explanation of) how PSFSlack works? Where are those folks posting from? (Direct message is fine)
[15:09:33] <PSFSlack> <deveshkusingh> bhrutledge: I asked di to add me to the bridge from slack to irc, which causes my name to be prefixed with PSFSlack
[17:10:23] <neilB> i was trying to run pip's test with tox and ran into a few errors. I noticed issue #8273 mentioned that virtualenv version greater than 20 breaks pip's tests.
[17:18:55] <PSFSlack> <deveshkusingh> tox should be able to pick a lower version of virtualenv, as defined in https://github.com/pypa/pip/blob/master/tools/requirements/tests.txt#L17
[17:20:03] <PSFSlack> <deveshkusingh> Which doesn't contain the virtualenv module, so the virtualenv defined in tox takes precedence
[17:23:17] <PSFSlack> <deveshkusingh> disclaimer: The above statement is based on my limited interaction with tox, and might not be correct
[17:56:58] <PSFSlack> <deveshkusingh> okay, and in your venv, you don't have virtualenv module installed? you can confirm it by `pip freeze` output
[17:59:45] <PSFSlack> <deveshkusingh> and the tox module you are using, is that installed within the virtualenv as well?
[18:06:21] <PSFSlack> <deveshkusingh> On my Mac, I just created a virtualenv, cloned pip inside it, installed it with `pip install -e .`, then installed tox in it and ran `tox -e py tests/functional/test_cache.py`
[18:32:28] <PSFSlack> <deveshkusingh> These are different errors then, I can see that legacy virtualenv is being used with tox from the logs
[23:09:07] <travis-ci> Change view : https://github.com/pypa/pip/compare/7ed5e12ae83ef90ac33be33555ea52f61457c1d2...d01bfcfaa13a4f06fa0ce61fa18cf06012f2e78f