Deprecate bdist_dumb, bdist_rpm, bdist_dmg, bdist_msi, bdist_wininst

Warehouse is planning on removing upload support for bdist_dumb, bdist_rpm, bdist_dmg, bdist_msi, and bdist_wininst:

• https://www.python.org/dev/peps/pep-0527/
• https://github.com/pypa/warehouse/issues/6792

CPython’s distutils deprecated bdist_wininst in 3.8:

• https://github.com/python/cpython/pull/14553
• https://discuss.python.org/t/deprecate-bdist-wininst/1929

And is planning on removing bdist_wininst in 3.9:

• https://github.com/python/cpython/pull/18329
• https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115

In this latter discussion, @pganssle said:

I think the right thing to do here would be to propose removing this [bdist_wininst] in setuptools, and drop the idea of removing it in distutils. The same goes for bdist_rpm and all the other weird non-wheel binary distributions.

---

What’s necessary to deprecate these in setuptools?

PR https://github.com/pypa/setuptools/pull/1764 deprecates bdist_egg. A similar pattern could be followed to add warnings in run() in bdist_rpm.py and bdist_wininst.py. Does this sound right?

But I’m less clear on bdist_dumb, bdist_dmg and bdist_msi. Are these handled by setuptools, and if so, where?

---

• bdist_dmg
• bdist_dumb
• bdist_msi
• bdist_rpm https://github.com/pypa/setuptools/pull/2780
• bdist_wininst https://github.com/pypa/setuptools/pull/2040

[jaraco]

* Am I missing the point and is setuptools only meant to be an interface to/from PyPI? (The host of other commands such as `build_sphinx` or `flake8` would indicate not.)

The primary motivation here is that Setuptools should no longer be a general-purpose packaging tool, but should focus on being a best-in-class build backend for the Python Packaging ecosystem, based on the standards set forth by the PyPA. To that end, Setuptools is seeking to deprecate setup.py <anything> and instead support the PEP 517 build backends, which only target building wheels. So yes, I would expect to discourage/deprecate usage of distutils commands such as build_sphinx and flake8.

The essential problem with supporting bdist_rpm is that it requires every Python project to adopt Setuptools to have RPM support.

Instead, probably what needs to happen is for someone to build a tool to convert wheels to RPMs. Then, that tool could generate an RPM from any wheel, including those built by other backends. Maybe that’s what pyp2rpm does.

[pganssle]

Thanks for kicking off this process, Hugo!

I think we can follow the road map from setup.py test and setup.py upload/register:

1. Add deprecation warnings for 9-12 months (with tests).
2. Document the deprecation.
3. During removal time, add new sub-commands that actively raise errors (rather than simply removing the commands from setuptools).

But I’m less clear on bdist_dumb, bdist_dmg and bdist_msi. Are these handled by setuptools, and if so, where?

setuptools is a wrapper around distutils (and hopefully eventually distutils will move into setuptools), so anything that’s setuptools doesn’t modify / monkey-patch just is passed through to distutils. The two options we have for deprecating bdist_dumb et al would be creating our own sub-command that raises a deprecation warning or monkey-patching the relevant commands in distutils. Normally monkey-patching is somewhat abhorrent to me, but in this case I’m inclined towards monkey-patching so that the warnings hit the greatest number of people (e.g. people who for some reason or another are subclassing distutils.command.dumb or whatever).

It would probably be nice for us to prepare a blog post or some other similarly “loud” announcement of these forthcoming removals. Probably we can do that during the deprecation period, though.