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. Archived: Python Extension Packages for Windows - Christoph Gohlke was a holdout at a time, but it has switched to distribute wheels for a while now.
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.
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: Fedora Packaging Guidelines :: Fedora Docs
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?
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?
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 )
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.
I am the person who’s done the most work on the Fundable Packaging Improvements page but anyone within the Packaging WG should be able to edit it, such as @EWDurbin or @ncoghlan or @ewa.jodlowska. Please feel free to talk with one of them about adding a section about this documentation work! (I’m very busy this month, and sorry for the delay in replying.)
Since the newest release (6.2.0), Pillow no longer uploadsbdist_wininst installers. There could still be a bug in PyPI that allows uploading them, because we uploaded them for the previous 6.1.0 release in July, and earlier quarterly releases.
)