Log file Viewer

[00:00:00] <ngoldbaum> https://github.com/pypa/setuptools/pull/1955

[00:00:10] <ngoldbaum> after merging that PR setuptools 45 got released

[00:00:54] <ngoldbaum> it looks like in some cases this is causing people to get errors saying that setuptools 45 isn't compatible with python2, even though it should technically work

[00:01:24] <techalchemy> ngoldbaum, well yeah

[00:02:43] <techalchemy> there's a pretty clear marker saying python_requires = >=3.5 and adding the py2_warn import right?

[00:02:59] <techalchemy> so you can technically install it but not using pip im guessing

[00:03:34] <ngoldbaum> the trouble is that many custom pypi mirrors don't export the necessary metadata for python_requires to work correctly, so yeah, pip complains when it sees the file

[00:04:06] <techalchemy> i mean, does pip actually even discover the right version now if you just install an unpinned setuptools on python 2?

[00:04:16] <techalchemy> will it discover setuptools 44?

[00:04:21] <ngoldbaum> yeah, if you are pinging pypi

[00:04:32] <ngoldbaum> but not other custom mirrors that e.g. openstack or whoever else has set up

[00:05:19] <techalchemy> oh cool

[00:05:37] <techalchemy> why wouldn't pip be able to read metadata on wheels it downloads from other places?

[00:05:46] <techalchemy> ohhhh nvm i actually know

[00:06:03] <ngoldbaum> https://discuss.python.org/t/packaging-and-python-2/662/137

[00:06:09] <techalchemy> ngoldbaum, yeah i know the answer

[00:06:57] <techalchemy> the candidate is selected before it's downloaded and the information is carried in the simple api url construct

[00:07:09] <techalchemy> most repository clones don't replicate that

[00:08:04] <ngoldbaum> so exarkun was seeing failing builds on circleci, presumably because it was pinging some pypi mirror to get setuptools

[00:08:24] <ngoldbaum> i also saw someone somehow getting setuptools 45 using pip 2

[00:08:47] <ngoldbaum> python 2 -> python 3 is the 2020 problem ;)

[00:09:06] <techalchemy> same issue though, if the repository doesn't supply the right metadata pip will just provide the latest setuptools

[00:09:30] <ngoldbaum> yup, it just goes to show you how the "pip install -U setuptools" idiom is so widespread

[00:10:16] <techalchemy> well yeah, it's been a critical component of python environments since there have been python environments

[00:10:20] <techalchemy> lol

[00:11:33] <exarkun> not quite that long.

[00:11:36] <techalchemy> and with various incompatibilities and a few breakages in the last year or two i think everyone knows the bugfixes are in the latest versions so just rely on those by default, I know I do

[00:12:08] <ngoldbaum> now i guess everyone will pin setuptools 44

[22:07:56] <squarebracket> i'm trying to install twine on centos 7, but it thinks the package is... broken? I get: "Running setup.py (path:/tmp/pip-build-iEBOyY/twine/setup.py) egg_info for package twine produced metadata for project name unknown. Fix your #egg=twine fragments."

[22:08:13] <squarebracket> if i upgrade pip, i no longer get that. is there a problem with the twine package?

[22:09:04] <squarebracket> oh, is this a python 2 being deprecated thing? :(