[FR] More gradual breakage of setuptools.command.test

[hauntsaninja]

What's the problem this feature will solve?

First, let me just say that I do not envy the position of maintaining setuptools, and if this issue is at all burdensome, please ignore it :-)

Regarding #4519, in the event that setuptools chooses to revert something (looks like issue is already top ten all time by emoji count), I'm wondering if there are creative ways to introduce this breakage more slowly

Describe the solution you'd like

Currently, anyone trying to install a package that has a test command breaks. This is unfortunate, because people may not even be using that test command (in fact, hopefully not, since that's been messaged for years), and so no one may even have have seen the warning.

Instead, we could maybe follow something like the following sequence of steps:

1. Add a deprecation warning in setuptools.command.test.__getattr__
2. Make run in setuptools.command.test.test raise an error

This would greatly increase the number of people to whom the warning is visible.
It would also accomplish the goal of killing python setup.py test, while not yet breaking installs from those package versions.

Code of Conduct

• I agree to follow the PSF Code of Conduct

[mkielar]

I'm just a regular Dev, having the same "happy morning" as probably 1/3 of the programming world, and in no way affiliated with setuptools. But the test command has been deprecated since 41.5.0 which was released almost 5 years ago.

I'd say that that was gradual enough ;)

[chrisirhc]

This is unfortunate, because people may not even be using that test command (in fact, hopefully not, since that's been messaged for years), and so no one may even have have seen the warning.

This is likely the crux of the issue. A breaking change would need to at least message at the point that is about to break.
In this case, if the plan was to break install on these packages, then the message should've been on the "install" for at least one major version.

This gives folks time to find workarounds, and also provides some time for the change to be rolled out with known workarounds.
However, I'm seeing people on #4519 scrambling to find workarounds. That's an indicator that the change wasn't gradual to these folks.

This isn't a ding on the contributors, I'm just stating my observation in the issues.

Add a deprecation warning in setuptools.command.test.getattr

Just a note on this, you could add a link to an open issue on Github so users can contribute workarounds there.

[purificant]

setuptools is core package in the python ecosystem, unfortunately now there are dozens of popular packages that are failing to install, there needs to be a better way to handle this deprecation end to end and not just within the confines of the setuptools codebase

[abravalheri]

This is likely the crux of the issue. A breaking change would need to at least message at the point that is about to break.
In this case, if the plan was to break install on these packages, then the message should've been on the "install" for at least one major version.

Hi @chrisirhc, please note that this message you are referring to was there for 5 years.

[manugarri]

setuptools is core package in the python ecosystem, unfortunately now there are dozens of popular packages that are failing to install, there needs to be a better way to handle this deprecation end to end and not just within the confines of the setuptools codebase

Exactly this, can we realistically expect the 100s of package maintainers (volunteers most of them) to be up to date on the state of a core build tool like setuptools? For a non trivial chunk of them, setuptools is just some copypaste template you use to turn your source code into a package.

[max-wittig]

Hi @chrisirhc, please note that this message you are referring to was there for 5 years.

@abravalheri But nobody know that it was planned to be removed so was it really deprecated, if nobody knew?

[deceze]

please note that this message you are referring to was there for 5 years.

As a user of setuptools/pip/poetry who uses this toolchain to install packages I need, this is the first time I've ever seen anything about this deprecation, and I've gotten to know about it by deploy tasks failing. This can't be the correct way to spread the word.

Yes, it has been the failure of many maintainers and/or developers sticking with old packages etc., but that's simply how this works in the real world. We oftentimes have to deal with old packages, end of story. setuptools is so deeply ingrained in so much of the Python ecosystem, removing anything from it must be treated with much much more caution than this has been. "There's been a message there nobody saw" isn't cutting it.