Deprecate bdist_wininst


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:

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. was a holdout at a time, but it has switched to distribute wheels for a while now.

See also : “Don’t install wininst*.exe on non-Windows platforms”.

October 2018, there was a discussion about the license of these files:

It was requested to not install these files on non-Windows platforms, but nothing was done. I created 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 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 and 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:

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: Éric Araujo wrote "FYI, this is fixed in the new bdist_rpm2 command: " but 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 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 I also had a discussion about which is clearly outdated: the doc which starts with “from distutils.core import setup” and then advices to use “python 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 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.

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.)

1 Like

Since the newest release (6.2.0), Pillow no longer uploads bdist_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.

PEP 527 is not “fully” implemented, some projects were grandfathered in and allowed to continue publishing the deprecated filetypes. I created to determine if this is still necessary.

1 Like

This list of packaging improvement ideas awaiting funding has now moved to and people can submit pull requests to suggest additions.