Update setup.py packaging before dropping Python 3.4 support #281
Comments
|
also related: #210 (comment) |
|
Setuptools is fine here, among alternatives I'd say Poetry looks nice, but when I checked it out it was lacking one feature which I personally wanted (grabbing a version from git tag). Yet, it gets better. I think if pyyaml was to cover the most popular env cases with wheels it wouldn't matter a lot how The solution should start with Also, looking at the current |
|
|
@webknjaz some PR are currently under development to allow poetry to retrieve project version from Else another alternative can be to use pbr, pbr is really straightforward to use and already have a lot of cool features (version, changelog, authors, requirements, etc...) |
|
|
`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/
`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/
`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/
|
Also, could you please eliminate |
|
Funny you mention it, I'd created a prototype pytest wrapper awhile back to surface pyyaml's "special" test suite as individual pytest tests- dusted it off and PR'd it at #588. I think all the points of the original issue have been addressed in the past couple releases, so I'm closing... |
setup.py needs to be updated to a newer technology than distutils before we drop support for another Python version. setuptools should be the "easiest" to leave most of the existing custom code in place to support the extension build and integrated testing, etc, but there are other options that I'm sure @webknjaz would love to talk about ;).
We properly updated setup.py's metadata when dropping Python 2.6 and 3.3 support, however, our setup.py is still based on distutils, which doesn't understand
python_requires(and prevents pypi from extracting the necessary metadata to ensure that unsupported Pythons will fall back to the last release that did support them). So today, anyone that's doingpip install pyyamlwith an unsupported Python will install the latest release, but it will bomb out at install-time with something likePyYAML requires Python '>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*' but the running Python is 2.6.9instead of installing a prior release that did support it.Since we've released one that way, the fallback to 3.13 will never work again unless all the intermediate releases were pulled (uh, no ;) ). So either we say "tough noogies" or we release a single 5.x version with Python 2.6 and 3.3 support listed (on a packaging framework that supports the right metadata) to fix the glitch.
The text was updated successfully, but these errors were encountered: