Deprecate bdist_wininst

Hi,

bdist_wininst uses the mbcs encoding which is only available on Windows. There is an issue open for 8 years to suggest to use UTF-8 or use the Unicode (wide character) flavor of the Windows API to support running bdist_wininst on non-Windows platforms and to be able to distribute binaries which don’t depend on the ANSI code page: https://bugs.python.org/issue10945

When I look at numpy or Cython: they don’t distribute .exe installers, but binary wheel packages for Windows. I understood the wheel packages is the recommended way to distribute binaries on Windows, and so that bdist_wininst is kind of deprecated.

Does anyone still use bdist_wininst?

Can we start to deprecate bdist_wininst in Python 3.9, and maybe remove it later? The removal can be discussed later.

I would simply suggest to not use bdist_wininst because of its implementation issues, but also because it’s annoying to have to run a GUI to install something, whereas pip can install dependencies in a CLI transparently without buggy the user with dialog boxes.

Maybe in some closed-door enterprise systems that don’t change because it has been working, but nothing public as far as I am aware of. https://www.lfd.uci.edu/~gohlke/pythonlibs/ was a holdout at a time, but it has switched to distribute wheels for a while now.

See also https://bugs.python.org/issue37468 : “Don’t install wininst*.exe on non-Windows platforms”.

October 2018, there was a discussion about the license of these files:
https://mail.python.org/pipermail/python-dev/2018-October/155507.html

It was requested to not install these files on non-Windows platforms, but nothing was done. I created https://bugs.python.org/issue37468 to make this change.

For what it’s worth, PyPI doesn’t even allow you to upload bdist_wininst (See PEP 527) anymore, so if you’re looking at PyPI to determine usage, you’re going to get no usage whatsoever for anything recent.

I don’t have any idea if other people are still using bdist_wininst and distributing them through some other mechanism.

From my perspective, nearly all direct invocations of setup.py are currently or are eventually heading for deprecation. PEP 517 doesn’t provide hooks to generate anything other than sdist or wheel, so basically all commands not actually triggered (directly or indirectly) by calling a PEP 517 front-end are suspect.

I have occasionally mused about the possibility of a “generic front-end” that would allow people to continue using the distutils command structure, but in an environment that allows them to declare their dependencies before invocation, but so far I think tox may be the closest thing to that.

Assuming we keep supporting some form of distutils commands, I think it would make sense to spin out some of the existing standard library commands into their own modules (e.g. bdist_rpm, bdist_wininst, probably others I’m not even familiar with), if anyone wants to use and maintain them.

Ok. I created https://bugs.python.org/issue37481 and https://github.com/python/cpython/pull/14553 to deprecate bdist_wininst in Python 3.9.

There are multiple projects to build any Python package into a RPM. We discussed that with my team at Red Hat, and in short, these projects are mostly useless, especially if the goal is to a package accepted in a Linux distribution. None of these tools respect the guidelines of each distribution. Example of Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/

bdist_rpm falls into the same category, and it does not seem to be maintained anymore. For example, it requires to pass a “–fix-python” parameter to produce a “correct” package. There is a bug open for 11 years: https://bugs.python.org/issue4459 Éric Araujo wrote "FYI, this is fixed in the new bdist_rpm2 command: https://bitbucket.org/tarek/pypi2rpm/changeset/ce6626df0225 " but https://bitbucket.org/tarek/pypi2rpm also seems to be unmaintained: latest commit 7 years ago.

So if you ask me my opinion, bdist_rpm should be deprecated/removed as well. But it doesn’t seem to cause much harm, so maybe it’s okish to keep it unmaintained?

Ok, I merged my https://github.com/python/cpython/pull/14553 PR: use bdist_wininst now emits a DeprecationgWarning, and the command is deprecated in the doc.

Now the question is if someone here wants to go further is deprecate all distutils commands except sdist and bdist_wheel? Steve Dower wants to deprecate bdist_msi as well: I’m not sure who use bdist_msi. It’s another form of GUI installer, so it’s similar to bdist_wininst. I would also strongly encourage to use bdist_wheel rather than bdist_msi.

In https://github.com/python/cpython/pull/14553 I also had a discussion about https://docs.python.org/dev/distutils/ which is clearly outdated: the doc which starts with “from distutils.core import setup” and then advices to use “python setup.py bdist_wininst”. I suggested to remove the doc, but Paul says that setuptools doc expect that readers already read distutils doc, so outdated distutils should be kept.

Would it be possible to create a grant to pay someone to update the distutils doc? With having in mind that distutils code will be moved into setuptools in the long term. So maybe copy distutils doc into setuptools doc, and then rewrite it to replace distutils with setuptools? Or even pay someone to move distutils into setuptools?

Who manage PSF packaging grants?

Probably a good idea, but I personally don’t have the time.

The PSF grants WG.

/cc @sumanah, who is maintaining https://wiki.python.org/psf/Fundable%20Packaging%20Improvements. The distutils-to-setuptools API moving work is already listed there.

Maybe a bug: Pillow still uploads bdist_wininst installers for Windows.

I think the others are fine to leave (though if people who work more closely with those tools want to say drop them then I’m fine with that too).

bdist_msi and bdist_exe don’t integrate with any other package managers, can’t be integrated with any other installer besides our own Python installer, and in any case are worse than simply copying the files. (If we had a bdist_msm I’d be slightly more sympathetic, but we don’t and probably should not :slight_smile: )

I also don’t necessarily think that wheels are always the alternative, particularly for embedded scenarios, but I do think that the fewer options we provide by default will help people find the option they actually need, rather than assuming that because it’s “blessed” it must see correct.