Missing Python 2.7 windows wheel on version 1.13.1

[pythonoi]

I noticed that there are Python 2.7 wheels built for mac and linux for this release, was wondering if it's possible for a Python 2.7 wheel for windows to be added to the PyPI download files for this release.

Thanks!

[GrahamDumpleton]

The build infrastructure used to build Python wheels from GitHub actions doesn't seem to be able to build Python 2.7 binary wheels on Windows. I don't remember the error, but it wasn't from memory anything obvious and something I could do anything about so there was no choice but to disable binary wheels for that combination.

How dependent are you on Python 2.7 on Windows?

Also be aware that Python 2.7 support will likely be dropped in wrapt 1.14.0 as someone has provided a PR to modernise various aspects of Python C API usage and this means finally dropping Python 2.7 support.

[ddanilko-sonova]

We suffered from this as well and could not build a wheel for 1.13.1 due to the following error:
error: Microsoft Visual C++ 9.0 is required. Get it from http://aka.ms/vcpython27
(note that the link ends up in a 404 so it's kind'a dead end). Unfortunately, we had to pinpoint an older version of wrapt in our requirements file.

@GrahamDumpleton The biggest problem that I see is that you do not update the major version when doing a backwards-incompatible change but increase the minor version instead. This is causing problems because it's not what most people expect. We are not using wrapt directly but pull it as a dependency of deprecated, which specifies a dependency to wrapt like that:

    install_requires=['wrapt < 2, >= 1.10'],

which is what I would do as well if I were them (== give me the latest compatible version of wrapt). However, we get a backwards-incompatible version 'out of the blue'...

@GrahamDumpleton please consider following semantic versioning, which according to https://semver.org/ means:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

Dropping support for any Python version or operating system is a backwards-incompatible change.

[GrahamDumpleton]

There were no incompatible API changes in the code of the package for 1.13.0. The Windows build issue for binary wheels when using Python 2.7 which is specific to whatever is being used by GitHub actions is only issue I know of. What are you suggesting was an incompatible API change in the package for 1.13.0? For dropping Python 2.7 support, then is fair enough that perhaps should be called 2.0.0, but those changes haven't made it in yet so no decision made on the version yet.

[ddanilko-sonova]

I agree that dropping support for Python 2.7 should be a major release (e.g. 2.0.0).

When it comes to backwards-incompatible changes in 1.13.0, I could spot a few:

• it dropped support for Python 3.4 (1474670)
• it stopped testing Python 2.7 on Windows (633ea18), which might mean effectively dropping support for this combination of Python version and operating system...

Would you agree that those two changes could have been backwards-incompatible for some people?

[ddanilko-sonova]

When it comes to the problem at hand (1.13.0 not being backwards-compatible with Windows+Python2.7), I think that the cleanest solution would be to remove 1.13.0 and 1.13.1 from PyPI and re-release them as 2.0.0. Otherwise, many users of your package would need to adapt their code to not update to 1.13.0 in case they still have systems using Windows+Python2.7.

Do you think that it would be possible to do so?

[GrahamDumpleton]

There is no backwards incompatibility with Windows+Python2.7. The only issue related to that is the specific system used to build wheels in which their environment is broken. The code is tested on other platforms for Python 2.7 and there is no platform specific code in the package so it should still work fine on Windows+Python2.7. So that isn't really going to be an issue. The only issue may be with Python 3.4 where an install may not work.

Anyway, I am going to discuss it with one of the CPython core committers who has been helping with some stuff in wrapt recently. They will have a better idea of what is reasonable given that Python 3.4 is long dead and no longer supported since March 18, 2019.

[tiran]

Graham has reached out to me and asked me to give my opinion on the issue.

Warning: strong opinion ahead

In my opinion it is unreasonable to request build artifacts for Python versions that have passed their end of lifetime. We, the CPython core developer team, have stopped supporting Python 2 not only to reduce our workload, but also spare 3rd party packages like wrapt the burden. If you cannot move away from Python 2, then I suggest that you either build Windows artifacts yourself, pay somebody to build wheels for you, or at least contribute a working solution for Windows builds.

SemVer is not a magic fix for this issue, too. Hynek has summarized the issues with SemVer in his article Semantic Versioning Will Not Save You.

May I suggest a more practical solution?

• Yank release 1.13.1 from PyPI.
• Drop support for all EOLed Python versions (3.5 and earlier) by adding python_requires = >= 3.6.
• Release 1.14.0 with binary wheels for Python 3.6 to 3.10 as well as PyPy 3.

Users of supported Python versions will get latest version while users of unsupported Python versions like 2.7 and 3.4 will get unsupported wrapt 1.12.1. IMHO that is reasonable and fair. Python 3.6 is the oldest Python version supported by cibuildwheel and also the oldest Python version that can targeted by limited API / abi3 (PR #187) with reasonable effort.

[ddanilko-sonova]

May I suggest a more practical solution?

Yank release 1.13.1 from PyPI.
Drop support for all EOLed Python versions (3.5 and earlier) by adding python_requires = >= 3.6.
Release 1.14.0 with binary wheels for Python 3.6 to 3.10 as well as PyPy 3.

Lovely ❤️ That's exactly what I would love to see with twoone small adjustments:

• we should yank both 1.13.0 and 1.13.1 from PyPI
• we should release the current code as 2.0.0 instead of 1.14.0, otherwise, packages like deprecated would still think it's a backwards-compatible release

EDIT: I just realized that if the support for Python 2.7 is dropped explicitly then pip will not install 1.14.0 in a Python 2.7 environment so after reconsidering, I agree that 1.14.0 is a good number 😉

By no means I wanted to ask for keeping active support for deprecated Python 2.7 - I would simply appreciate not braking existing systems by not mentioning dropping support for them and by mentioning I mean bumping the major release version 😉

[tiran]

I don't see any reason to bump the major version number. wrapt does neither use SemVer nor does 1.14.0 introduce a backwards incompatible API change.

[ddanilko-sonova]

If wrapt does not plan to adhere to semantic versioning now nor in the future, then I guess there is nothing more to do here... Re-releasing 1.13.0 as 1.14.0 does make any sense and does not change anything for its users... 😞

Thanks for your time and hard work in developing open source projects 🍻

[pythonoi]

If it's hard to build for windows-27 and this project is going to be Python 3 only in the near future, I agree with @tiran proposed solution. This will allow the project to move onto Python 3 only 😄 and users who are dependent on py2 will not get updates or installation failures. For now, I'll just pin on py2 as others who have referenced this issue have done and you can feel free to close this issue with whatever approach you decide.

Thanks for your time and responses!

[andy-maier]

Many of our projects that test on Github Actions have also suffered from the error mentioned further up:

error: Microsoft Visual C++ 9.0 is required. Get it from http://aka.ms/vcpython27

The workaround for us was to pin wrapt to <1.13. on Python 2.7 and Python 3.4. It is not pinned on Python 3.5 and higher.

This time, I did not want to hold back with my opinion on dropping Python 2.7 and 3.4 support:

As long as major Linux distributors still support Python 2.7 and 3.5 on their behalf (RedHat is one such example), dropping that support makes life quite difficult for maintainers of Python packages that are included in such Linux distributions.

The only possible solution in such cases seems to be to pin dependent packages, because the maintainers of packages who dropped support for old Python versions often refuse to fix old versions of their packages. So the effort to deal with such decisions is nearly always on the side of the owners of packages that depend on the packages that have dropped the support. In other words, a package that drops support for old Python versions has made their own life easier at the cost of dependent packages that cannot afford to also do that. For example, I am spending my sunday morning today for pinning wrapt to <1.13 in seven Python projects that use Pylint, and in most cases in both the master branch and the latest stable branch of them. And those are just the most important ones, I will have to do that over time in all the others, too.

One consequence of dropping support for older Python versions is that this leads to increasingly not being able to fix functional defects and also security issues, because the dependent packages just stay pinned to the latest version that still supports the Python version in question.

As much as I personally would like to move forward with Python versions and drop old stuff, the reality out there is different and I see Python package maintainers being increasingly disconnected with that part of reality. If we as package maintainers try to force users forward by dropping support for old versions, but Linux distributions are not with us on this path, then there is a significant disconnect that ultimately goes at the expense of our users.