pmxbot IRC Log Viewer

[19:23:06] <pyusr> argh !, question, is setuptools 45.0.0 still supporting python 2, or not ?

[19:27:07] <toad_polo> pyusr: Not.

[19:27:43] <toad_polo> I mean, I believe it will work if you manage to install it.

[19:27:53] <pyusr> OK, can someone please yank it from Pypi ? I think it will solve this issue: https://github.com/pypa/packaging-problems/issues/325

[19:28:04] <toad_polo> pyusr: No.

[19:28:35] <pyusr> Since 45.0.0 is catagorized as: https://pypi.org/project/setuptools/45.0.0/#files setuptools-45.0.0-py2.py3-none-any.whl

[19:28:48] <pyusr> pip 8 sees it as py2, and installs it instead of 44.whatever.is.the.last.py2.version

[19:28:59] <pyusr> and then all hell breaks loose

[19:29:23] <toad_polo> Pretty sure it wouldn't work even if we pulled the wheel.

[19:29:36] <pyusr> I think it will, since pip8 installs 45.0.0 not 45.2.0

[19:29:42] <pyusr> why would it do that ?

[19:29:48] <toad_polo> You need to upgrade pip or Python.

[19:30:04] <pyusr> we've been that, not very possible

[19:30:13] <pyusr> why not remove 45.0.0 are label it py3 only ?

[19:30:47] <toad_polo> Because it's not really inaccurate and it's not causing problems for anyone using supported platforms.

[19:31:10] <toad_polo> Including Python 2, but excluding old pips.

[19:31:31] <toad_polo> If you can upgrade setuptools you can upgrade pip.

[19:31:41] <pyusr> ok, now it's atleast Pypa hurting the comunity and not ubutu or someone else

[19:31:46] <pyusr> you cant, read that bug

[19:31:56] <toad_polo> Nope, definitely ubuntu.

[19:34:07] <toad_polo> Nothing about that bug says that you can't upgrade pip.

[19:34:58] <pyusr> again, read it, python-virtualenv uses pip8 to install the venv (with wrong setuptools_)

[19:35:16] <pyusr> and in ubuntu python-virtualenv uses a vendoered pip8,

[19:35:56] <toad_polo> Anyway, pulling 45.0.0 is not really possible because people may and likely are pinning it.

[19:36:42] <toad_polo> AFAIK warehouse doesn't have yank support yet, so that avenue is foreclosed to us.

[19:37:52] <toad_polo> pyusr: I read it. You just have to either upgrade pip first, then "upgrade" setuptools, or create the virtualenv without setuptools.

[19:39:31] <toad_polo> Or stop using old pips and old pythons.

[19:45:30] <pyusr> toad_polo: people have tons of CI/CD which work on this

[19:45:38] <pyusr> anyhow, dont yank 45.0.0 change it to withotu py2

[19:45:46] <toad_polo> It's not possible to change.

[19:45:50] <toad_polo> You can just yank.

[19:46:03] <toad_polo> AFAIK, anyway.

[19:46:28] <pyusr> I'm contemplating opening another bug report on this instead of this one

[19:46:33] <pyusr> since this one didn't describe the problem

[19:46:56] <toad_polo> I wouldn't, it would just annoy people.

[19:47:19] <pyusr> I already saw production CI/CD failing in other places, so I hope this will annoy people to fix it

[19:47:26] <pyusr> pypi is managed by pypa itself

[19:47:30] <pyusr> they can manually rename the file there

[19:48:00] <pyusr> and it is a bug which violates some PEP

[19:48:07] <pyusr> calling a py3 only package with py2 as well

[19:48:58] <pyusr> here is pypy's buildbot failing because of this bug: http://buildbot.pypy.org/builders/jitbackendonly-own-linux-armhf-v7/builds/1618/steps/shell_6/logs/stdio

[19:52:53] <pyusr> now I need to read pip's source code to make sure thats the bug

[20:02:31] <pyusr> hmm... ok, this bug is even weired....

[20:09:32] <pyusr> Ok, let's see if I get it right now:

[20:23:03] <ngoldbaum> pyusr: FWIW the tone you're taking isn't one that's likely to attract much help

[20:28:28] <ngoldbaum> also i'm pretty sure it's perfectly cromulent to have a universal py2.py3 wheel that doesn't support python2

[20:30:03] <pyusr> https://github.com/pypa/packaging-problems/issues/325#issuecomment-591053416

[20:31:21] <toad_polo> ngoldbaum: It actually even *does* support Python 2.

[20:31:45] <toad_polo> Like, it works just fine if you manage to install it, it just raises an annoying warning to tell you, "Something in your pipeline has gone horribly wrong."

[20:32:38] <pyusr> toad_polo: I belive you are wrong

[20:32:39] <pyusr> https://github.com/pypa/setuptools/blob/v45.0.0/setup.cfg#L50

[20:32:48] <pyusr> that line is what causes all the hell to happen after it's installed

[20:32:54] <ngoldbaum> pyusr: lol he's not wrong

[20:32:57] <toad_polo> pyusr: No, I'm not wrong.

[20:32:59] <pyusr> as you can see: http://buildbot.pypy.org/builders/jitbackendonly-own-linux-armhf-v7/builds/1618/steps/shell_6/logs/stdio

[20:33:03] <pyusr> ERROR: Package 'setuptools' requires a different Python: 2.7.12 not in '>=3.5'

[20:33:24] <pyusr> so where is that ERROR from ?

[20:33:50] <toad_polo> Evidently pip checks the requires metadata and is telling you that you've got the wrong version installed.

[20:34:04] <ngoldbaum> note that statement is orthogonal from toad_polo's previous statement

[20:34:06] <pyusr> ahh, ok, so, we are in a meh situation

[20:34:10] <toad_polo> Because setuptools is saying, "You shouldn't install this if you aren't on Python 3.5 or greater", even though the code will still work.

[20:34:15] <ngoldbaum> there's some nuance here and your tone makes it difficult to get that accross

[20:34:50] <toad_polo> I personally don't like that `pip` raises an *exception* when you try to install something that declares the wrong python_requires.

[20:35:47] <toad_polo> I always thought python_requires was more useful as a thing that helped you find which version to install, but if you've deliberately chosen to install it, or if you've ignored the metadata, `pip` should probably let you install it.

[20:36:04] <pyusr> so it's compatible yet practically useless ?

[20:36:10] <toad_polo> Either way it would be nice to have a flag to be like, "Do it anyway I know what I'm doing" or "Be extra strict and don't let me install this stuff."

[20:36:16] <ngoldbaum> if you did "python setup.py install" it'd probably work

[20:36:36] <toad_polo> For certain values of "work"

[20:36:43] <toad_polo> And also it's already a wheel.

[20:36:56] <ngoldbaum> i think you could just have a version constraint when you update setuptools?

[20:37:02] <ngoldbaum> like "pip install setuptools<45

[20:37:05] <ngoldbaum> or whatever

[20:37:34] <toad_polo> pyusr: No it's not useless, pip just complains about it I guess.

[20:37:48] <pyusr> I understand this, yet I think that in the end for all users, replacing setuptools-45.0.0-py2.py3-none-any.whl with setuptools-45.0.0-py3-none-any.whl will make everything work again

[20:37:49] <ngoldbaum> it could probably also be fixed in ubuntu or debian, i think there's even a canonical employee in that github thread

[20:37:59] <ngoldbaum> except for people who are using that file

[20:38:51] <pyusr> yes, but they are more limited in choice, or change their pip in an LTS version, which they almost never do , or patch it in somehow

[20:38:55] <toad_polo> Anyway, I doubt you'll get much in the way of support for this.

[20:39:15] <pyusr> and changing setputools 45.0.0-py2 to just -py3 would have no downside for anyone, and it will work

[20:39:29] <ngoldbaum> what about people who are using that file?

[20:39:31] <ngoldbaum> e.g. in automation

[20:39:48] <pyusr> even 45.0.0 changes file states https://github.com/pypa/setuptools/blob/v45.0.0/CHANGES.rst "Drop support for Python 2. Setuptools now requires Python 3.5 or later."

[20:39:49] <ngoldbaum> i would be very surprised if someone could yank a setuptools release without that breaking lots and lots of things

[20:39:54] <toad_polo> If you think that "Oh no this shouldn't break because a lot of people are using this LTS version that's supposed to be stable" then you should probably take that up with the people who sold you on that idea.

[20:40:06] <ngoldbaum> focusing on the "py2" string in the wheel filename is not going to be a productive use of your time

[20:40:07] <toad_polo> pyusr: We know. We know exactly what the guarantees are.

[20:40:08] <toad_polo> We're the ones who did it.

[20:40:44] <pyusr> Ok, think we can end this round of discussions

[20:40:45] <toad_polo> Like, this is not new information.

[20:42:32] <ngoldbaum> i don't understand why it's so awful just to update your CI scripts

[20:42:38] <ngoldbaum> i have to do that all the time because things break

[20:42:43] <ngoldbaum> even on LTS distros ;)

[20:42:51] <ngoldbaum> especially things that talk to network services like pypi

[20:46:52] <pyusr> I'm trying to help all the clueless people who have no idea what setuptools or pip is, and just run stuff that stop working

[20:49:55] <pyusr> and finding a practical solution for them (altough I agree, if they somehow cached in their artifactory 45.0.0-py2.py3 they are borked on that front)

[20:51:04] <ngoldbaum> this is one of the many reasons why "never ever use the system python" is pretty common python advice

[20:55:23] <pyusr> I agree but then again in terms of practically a high percentage does just that

[20:55:55] <pyusr> and in the end it's a question of being correct or solving a problem, and I understand it's a good question who should do what

[20:56:13] <pyusr> welp, hopefully I won't be touching that anymore ? g'night

[20:57:06] <pyusr> I won't tell you the horrors I've just seen by trying to investigate why once it's 45.0.0 and once it's 45.2.0

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 25th of February, 2020