The supported Python versions are not honored by pip #375
Assignees
Comments
andy-maier
changed the title
andy-maier
changed the title
|
I was just poking at issues with this for both Ansible and pyyaml (see #374). It's specified properly in setup.py, but because it's using distutils instead of setuptools for the build, it's not getting generated into the PKG-INFO properly. Rewriting the install (esp with all the extension compilation stuff) to be "native setuptools" is probably not on the table (at least for me right now), but this hybrid approach seems to work ok. I tried a version that would fall back to distutils if the setuptools import broke, but there was some brittle weirdness. I'm personally OK with requiring setuptools to install (hey, it's 2020), but that's probably not a decision I should make unilaterally... |
|
Does distutils even support |
|
It doesn't, which is the problem. The pyyaml install code is ancient and very custom due to pyyaml's 2/3 split codebase (among other things). Piecemeal switching just the |
|
+1 for hard build requirement on setuptools. split codebase is not ideal, most projects opt for a compat layer, but I guess that ship has sailed. |
|
We'll probably do the hard setuptools requirement for 5.4- that should hopefully fix the PyPI metadata issues for new releases, but I don't think there's anything we can do for the older ones to prevent them from being installed by incompatible Python versions. |
Totktonada
added a commit
to tarantool/tarantool-python
that referenced
this issue
Aug 21, 2020
`pip install pyyaml` fails in AppVeyor on 64-bit Python 3.4 with the following message (full log is in [1]): | Collecting pyyaml | Downloading <...>/PyYAML-5.3.1.tar.gz (269kB) | <...> | building '_yaml' extension | Traceback (most recent call last): | <...> | File "C:\Python34-x64\lib\distutils\msvc9compiler.py", line 287, in query_vcvarsall | raise ValueError(str(list(result.keys()))) | ValueError: ['path'] It is cumulative effect of several problems. The first one is that pip does not choose a PyYAML version, which supports given Python version (it is PyYAML 5.2, see [2]), but tries to install a last one (it is PyYAML 5.3.1 ATM). There are PyYAML issues [3], [4] and [5], which are not exacly about this, but looks tightly related. Despite Python 3.4 is not officially supported in PyYAML, it works on 3.4 in fact, so it is not the problem per se. Next, there are no wheels for Python 3.4 for PyYAML 5.3.1 on PyPI (which is logical), so pip downloads the source tarball and tries to build it. And the exception shown above is raised. It looks similar to [6], so I would guess that it is a compiler setup problem within an AppVeyor Windows image. I started the discussion [7] regarding it, but we need to work the problem around. Side note: 32-bit Python 3.4 works fine, the problem appears only for the 64-bit Python 3.4 build. In order to workaround the compiler setup problem we can just choose a PyYAML version for which PyPI provides wheels for the corresponding platform / Python version / Python build. It is 5.2b1, see [8]. Python 3.4 reaches EOL 2019-03-18 with releasing 3.4.10 (see [9]). I would not consider it as the reason to drop support of it on our side, especially when we're tell about a library (our users has its users, etc) and it is hard to estimate the impact. The problem we meet here is just about a testing dependency in a particular environment. So let's keep Python 3.4 support until there will be a better reason to stop. [1]: https://ci.appveyor.com/project/tarantool/tarantool-python/builds/34769695/job/ww3s69pkuh1n9d1y [2]: yaml/pyyaml#345 [3]: yaml/pyyaml#281 [4]: yaml/pyyaml#375 [5]: yaml/pyyaml#398 [6]: https://stackoverflow.com/a/43711372/1598057 [7]: http://help.appveyor.com/discussions/problems/28023 [8]: https://pypi.org/project/PyYAML/5.2b1/#files [9]: https://www.python.org/downloads/release/python-3410/
Totktonada
added a commit
to tarantool/tarantool-python
that referenced
this issue
Aug 21, 2020
`pip install pyyaml` fails in AppVeyor on 64-bit Python 3.4 with the following message (full log is in [1]): | Collecting pyyaml | Downloading <...>/PyYAML-5.3.1.tar.gz (269kB) | <...> | building '_yaml' extension | Traceback (most recent call last): | <...> | File "C:\Python34-x64\lib\distutils\msvc9compiler.py", line 287, in query_vcvarsall | raise ValueError(str(list(result.keys()))) | ValueError: ['path'] It is cumulative effect of several problems. The first one is that pip does not choose a PyYAML version, which supports given Python version (it is PyYAML 5.2, see [2]), but tries to install a last one (it is PyYAML 5.3.1 ATM). There are PyYAML issues [3], [4] and [5], which are not exacly about this, but looks tightly related. Despite Python 3.4 is not officially supported in PyYAML, it works on 3.4 in fact, so it is not the problem per se. Next, there are no wheels for Python 3.4 for PyYAML 5.3.1 on PyPI (which is logical), so pip downloads the source tarball and tries to build it. And the exception shown above is raised. It looks similar to [6], so I would guess that it is a compiler setup problem within an AppVeyor Windows image. I started the discussion [7] regarding it, but we need to work the problem around. Side note: 32-bit Python 3.4 works fine, the problem appears only for the 64-bit Python 3.4 build. In order to workaround the compiler setup problem we can just choose a PyYAML version for which PyPI provides wheels for the corresponding platform / Python version / Python build. It is 5.2b1, see [8]. Python 3.4 reaches EOL 2019-03-18 with releasing 3.4.10 (see [9]). I would not consider it as the reason to drop support of it on our side, especially when we're tell about a library (our users has its users, etc) and it is hard to estimate the impact. The problem we meet here is just about a testing dependency in a particular environment. So let's keep Python 3.4 support until there will be a better reason to stop. [1]: https://ci.appveyor.com/project/tarantool/tarantool-python/builds/34769695/job/ww3s69pkuh1n9d1y [2]: yaml/pyyaml#345 [3]: yaml/pyyaml#281 [4]: yaml/pyyaml#375 [5]: yaml/pyyaml#398 [6]: https://stackoverflow.com/a/43711372/1598057 [7]: http://help.appveyor.com/discussions/problems/28023 [8]: https://pypi.org/project/PyYAML/5.2b1/#files [9]: https://www.python.org/downloads/release/python-3410/
Totktonada
added a commit
to tarantool/tarantool-python
that referenced
this issue
Aug 21, 2020
`pip install pyyaml` fails in AppVeyor on 64-bit Python 3.4 with the following message (full log is in [1]): | Collecting pyyaml | Downloading <...>/PyYAML-5.3.1.tar.gz (269kB) | <...> | building '_yaml' extension | Traceback (most recent call last): | <...> | File "C:\Python34-x64\lib\distutils\msvc9compiler.py", line 287, in query_vcvarsall | raise ValueError(str(list(result.keys()))) | ValueError: ['path'] It is cumulative effect of several problems. The first one is that pip does not choose a PyYAML version, which supports given Python version (it is PyYAML 5.2, see [2]), but tries to install a last one (it is PyYAML 5.3.1 ATM). There are PyYAML issues [3], [4] and [5], which are not exacly about this, but looks tightly related. Despite Python 3.4 is not officially supported in PyYAML, it works on 3.4 in fact, so it is not the problem per se. Next, there are no wheels for Python 3.4 for PyYAML 5.3.1 on PyPI (which is logical), so pip downloads the source tarball and tries to build it. And the exception shown above is raised. It looks similar to [6], so I would guess that it is a compiler setup problem within an AppVeyor Windows image. I started the discussion [7] regarding it, but we need to work the problem around. Side note: 32-bit Python 3.4 works fine, the problem appears only for the 64-bit Python 3.4 build. In order to workaround the compiler setup problem we can just choose a PyYAML version for which PyPI provides wheels for the corresponding platform / Python version / Python build. It is 5.2b1, see [8]. Python 3.4 reaches EOL 2019-03-18 with releasing 3.4.10 (see [9]). I would not consider it as the reason to drop support of it on our side, especially when we're tell about a library (our users has its users, etc) and it is hard to estimate the impact. The problem we meet here is just about a testing dependency in a particular environment. So let's keep Python 3.4 support until there will be a better reason to stop. [1]: https://ci.appveyor.com/project/tarantool/tarantool-python/builds/34769695/job/ww3s69pkuh1n9d1y [2]: yaml/pyyaml#345 [3]: yaml/pyyaml#281 [4]: yaml/pyyaml#375 [5]: yaml/pyyaml#398 [6]: https://stackoverflow.com/a/43711372/1598057 [7]: http://help.appveyor.com/discussions/problems/28023 [8]: https://pypi.org/project/PyYAML/5.2b1/#files [9]: https://www.python.org/downloads/release/python-3410/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Update: After realizing that PyYAML 5.1 had introduced the use of the
python_requiresargument, I had to rephrase this issue completely.The
python_requiresargument ofsetup()specified since PyYAML 5.1 is not honored by pip. For example,pip install pyyamlon Python 3.4 happily installs PyYAML 5.1.2 which does not support Python 3.4.That is consistent with the fact that the Pypi page for PyYAML does not show the required Python versions in its Meta section. Compare that for example with the Python versions shown in the Meta section of the Pypi page for pywbem.
I don't have immediate advice how to fix that, but I think it has to do with how the package is built or uploaded to Pypi.
The text was updated successfully, but these errors were encountered: