6 ms·

Some packages are no longer installable after test command is removed

56 points by pcwelder 2y ago

denotational 2y ago
Particularly sad that even projects that attempt to pin their dependencies are running into this issue: if a dependency doesn’t have a pre-built wheel, then it will be built in an “isolated” environment, which means it won’t inherit a pinned setuptools version from the root project, and will instead pull the latest (unless the dependency itself is pinning setuptools). Reproducible builds can’t come too soon.
- pjc50 2y ago
  Having "install package" and "build package from source" be indistinguishable command lines is yet another massive design failure in the Python packaging system. It may sometimes, vaguely, work on the original programmer's machine. But the build environment isn't reproducible, and on Windows is often not present at all so installing the package simply falls over. (yes, we're using GRPC-on-Windows-Python, which means we're tied to the release schedule of wheels for that)
  - physicsguy 2y ago
    Until about 7 or 8 years ago, install pretty much always meant build from source; wheels only came in fairly recently in the history of Python and are still not universal, as you've found out. You'll typically have problems on: * ARM Linux * POWER9/10 * Alpine distros which use MUSL for the C library (https://rpep.dev/posts/alpine-python-antipattern/ https://rpep.dev/posts/alpine-python-antipattern/) * Some packages which depend on C libraries that are difficult to build on Windows (fault of the C libraries rather than Python really). Conda (and previous tools before it like Enthought Canopy) were designed to try to fix this problem, since the core Python packaging tooling just wasn't good enough. Wheels were proposed as a PEP extension and adapted but it took years for common packages to be built as wheels and even now there's nowhere near universal coverage for them even on common platforms.
    - eesmith 2y ago
      I only have source releases for macOS as I can't figure out how to include OpenMP for the binary wheels of my proprietary package.
      - physicsguy 2y ago
        You can't really do it, the best way is to build it with Clang installed with Homebrew and then put in the installation instructions to ask users to install OpenMP with `brew install libomp`. It really frustrates me that Apple strip it out of their build of Clang in favour of pushing their own Grand Central Dispatch.
rnmmrnm 2y ago
[flagged]
- Retr0id 2y ago
  (affectionate)
- guappa 2y ago
  [flagged]
justinclift 2y ago
Ugh. I've been trying to get my recently rebuilt desktop compiling a Python program (Redash) today, and it's been refusing to build due to this exact problem. Have spent hours on this, trying to get it working first on my Proxmox desktop, then in VMs, and was now testing in a stock standard Debian VM. It turns out it's an upstream bug. --- The steps here (for poetry users) worked for me: https://github.com/pypa/setuptools/issues/4519#issuecomment-2255446798 https://github.com/pypa/setuptools/issues/4519#issuecomment-...
timthelion 2y ago
Can we somehow vote to just stop having setuptools be maintained? When it breaks it wasts years of collective developer time and it really doesn't need to change at this point...
baq 2y ago
> This functionality has been deprecated for 5 years I used to think that 5 years is a long time when I was younger... that was before I had to maintain multiple legacy codebases. The biggest problem here is that it's a yet another pinning mechanism (PIP_CONSTRAINT) which most people didn't need[0] to know about until today. [0] need is defined here as 'production works without having to know this'.
- frankjr 2y ago
  It was printing a warning about the deprecation for close to 5 years. I don't think a few more years of support would make much of a difference. > WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. https://github.com/pypa/setuptools/commit/cd84510713ada48bf33d4efa749c2952e3fc1a49 https://github.com/pypa/setuptools/commit/cd84510713ada48bf3...
  - baq 2y ago
    Nobody reads these. It’s alert noise. If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.
    - kalaksi 2y ago
      I wouldn't say it's zero cost. It's a risk with potential to cost you. So there's some kind expected value to that cost and the risk grows the longer you ignore the warning
      - baq 2y ago
        I kind of agree - though I make a distinction between risk and cost in the same way you say 'potential cost' i.e. cost is realized risk. Until the risk materializes, you don't pay. The base scenario in this case is the classic thanksgiving turkey though - everything is fine until it isn't.
    - 2y ago
s1mn 2y ago
For those caught out by this, I put together a Github repo that shows how you can work around it in your Github Actions. Hope it helps! https://github.com/simonwhitaker/setuptools-demo https://github.com/simonwhitaker/setuptools-demo
jeroenhd 2y ago
It says a lot about the way this tooling is being used that five years of deprecation warnings still isn't enough to get people to port over their software. Perhaps this should've been implemented as a gradual failure with a temporary workaround ("as of X, this feature will break unless you specify the MY_CODE_WILL_BREAK_IN_OCTOBER=1 environment variable" rather than just breaking after an update), though I doubt that would've changed much.
- enriquto 2y ago
  Or maybe, you know, just don't knowingly break other people's working code.
  - skeledrew 2y ago
    And so never improve the language and ecosystem.
    - enriquto 2y ago
      Linux and Windows keep supporting even blatant bugs for decades, in order not to break old working code that relies on these bugs. The ecosystem keeps evolving healthily under that constraint. Breaking working code for an essentially stylistic change of API is not even malice. It's plain stupidity.
      - skeledrew 2y ago
        An OS isn't touched anywhere near as much by a diverse user base as a language and ecosystem like Python is. It can be more or less guaranteed that everyone building things directly on top of an OS already has a very good idea of what they're doing, and are likely aware of any strange quirks or workarounds they may need to consider. And if they don't, they know how and where to seek help. This is definitely not the case with most Python users, and as such, when bugs and bad practices can be remedied or mitigated they should be, so the many who just want to get their pipeline or automation scripts going can do so without polluting 101 channels with low quality questions and time-wasting problems.
deleted 2y ago
[deleted]
a_cool_username 2y ago
The pypa team are just not capable stewards of core aspects of the python ecosystem. As a maintainer and developer of Python based tools and libraries it is very frustrating having these folks push some change that they want and simply oopsie a significant chunk of the Python ecosystem, and then go dark for hours. They've done it this time by making poor architectural decisions ("Isolated builds should install the newest setuptools") and then add in poor library maintenance decisions ("We'll remove this feature used by thousands of packages that are still in use as active dependencies today"). Possibly each of these decisions were fine in a vacuum, but when you maintain a system that people depend upon like this, you can't simply push this stuff out without thinking about it. And if you do decide to do those things, you can't just merge the code and call it a day without keeping an eye on things and figuring out if you need to yank the package immediately! This isn't rocket science, everyone else developing important libraries in Python world has mostly figured this stuff out. In classic pypa form, it sounds like there was a deprecation warning but it only showed up if you ran the deprecated command explicitly, while the simple presence of this command causes package installs to fail. You have to at least warn on the things that will trigger the error! These days I try to rely on the absolute minimum number of packages possible, in order to minimize my pypi exposure. That's probably good dev practice anyway, but is really disappointing that I can't rely on third party libraries basically at all in Python, when the vast pypi package repository is supposed to be a big selling point of the language. But as a responsible developer I must minimize my pip / setuptools surface area, as it's the most dangerous and unreliable part of the language. Even wrapper tools are not safe, as you see in the thread.
- guappa 2y ago
  You might want to try getting them from apt-get. They're usually more stable there and get patched if they fail to install or fail to work with a newer version of something else.
skeledrew 2y ago
Looks like Python 2 -> 3 all over again. Something is deprecated for a very long time, people ignore the warning, and then cry foul when the thing is removed. Is there to be no cleanup and advancement in the language/ecosystem?
- eesmith 2y ago
  As I understand it, the warning was only generated on "python setup.py test", and not on "from setuptools.command import test", which was the deleted module. If you never used 'setup.py test' then the warning was never generated. Pulling up the first repo example I saw in the issue, https://github.com/IBM/python-sdk-core/commits/main/setup.py https://github.com/IBM/python-sdk-core/commits/main/setup.py back in 2019 was created using from setuptools.command.test import test as TestCommand ... class PyTest(TestCommand): ... code to forward to py.test ... setup( ... cmdclass={'test': PyTest}, ...) This was a clear adapter to use setup.py as a test runner, rather than using "pytest". Most likely they all started using "pytest" and forgot that the adapter was there. It wasn't used and never generated warnings. This is confirmed in the commit message from two hours ago at https://github.com/IBM/python-sdk-core/commit/bd44dd1152e01bb381f95e6295103991c0dd9ac4 https://github.com/IBM/python-sdk-core/commit/bd44dd1152e01b... : > That means there will be no more `python setup.py test`, but it wasn't be used for a long time.
  - skeledrew 2y ago
    That makes sense. At least they aren't making a fuss about it too, and just did the update to resolve it. I see a setuptools maintainer also did a partial rollback to provide a minimal fix. Hopefully everyone has updated their stuff by the time the minimal fix is also to be removed. Also I fell like this says something important about testing practices. Code should be exercised enough with sufficient coverage, and anything not covered reviewed periodically to see if it can be updated or removed.
justinclift 2y ago
Looks like this was fixed a few hours ago, by the release of a new (patched) version 72.1.0 of setuptools: https://github.com/pypa/setuptools/releases/tag/v72.1.0 https://github.com/pypa/setuptools/releases/tag/v72.1.0

56 points by pcwelder 2y ago

Particularly sad that even projects that attempt to pin their dependencies are running into this issue: if a dependency doesn’t have a pre-built wheel, then it will be built in an “isolated” environment, which means it won’t inherit a pinned setuptools version from the root project, and will instead pull the latest (unless the dependency itself is pinning setuptools). Reproducible builds can’t come too soon.

pjc50 2y ago
Having "install package" and "build package from source" be indistinguishable command lines is yet another massive design failure in the Python packaging system. It may sometimes, vaguely, work on the original programmer's machine. But the build environment isn't reproducible, and on Windows is often not present at all so installing the package simply falls over. (yes, we're using GRPC-on-Windows-Python, which means we're tied to the release schedule of wheels for that)
- physicsguy 2y ago
  Until about 7 or 8 years ago, install pretty much always meant build from source; wheels only came in fairly recently in the history of Python and are still not universal, as you've found out. You'll typically have problems on: * ARM Linux * POWER9/10 * Alpine distros which use MUSL for the C library (https://rpep.dev/posts/alpine-python-antipattern/ https://rpep.dev/posts/alpine-python-antipattern/) * Some packages which depend on C libraries that are difficult to build on Windows (fault of the C libraries rather than Python really). Conda (and previous tools before it like Enthought Canopy) were designed to try to fix this problem, since the core Python packaging tooling just wasn't good enough. Wheels were proposed as a PEP extension and adapted but it took years for common packages to be built as wheels and even now there's nowhere near universal coverage for them even on common platforms.
  - eesmith 2y ago
    I only have source releases for macOS as I can't figure out how to include OpenMP for the binary wheels of my proprietary package.
    - physicsguy 2y ago
      You can't really do it, the best way is to build it with Clang installed with Homebrew and then put in the installation instructions to ask users to install OpenMP with `brew install libomp`. It really frustrates me that Apple strip it out of their build of Clang in favour of pushing their own Grand Central Dispatch.

rnmmrnm 2y ago

[flagged]

Retr0id 2y ago
(affectionate)
guappa 2y ago
[flagged]

justinclift 2y ago

Ugh. I've been trying to get my recently rebuilt desktop compiling a Python program (Redash) today, and it's been refusing to build due to this exact problem. Have spent hours on this, trying to get it working first on my Proxmox desktop, then in VMs, and was now testing in a stock standard Debian VM. It turns out it's an upstream bug. --- The steps here (for poetry users) worked for me: https://github.com/pypa/setuptools/issues/4519#issuecomment-2255446798 https://github.com/pypa/setuptools/issues/4519#issuecomment-...

timthelion 2y ago

Can we somehow vote to just stop having setuptools be maintained? When it breaks it wasts years of collective developer time and it really doesn't need to change at this point...

baq 2y ago

> This functionality has been deprecated for 5 years I used to think that 5 years is a long time when I was younger... that was before I had to maintain multiple legacy codebases. The biggest problem here is that it's a yet another pinning mechanism (PIP_CONSTRAINT) which most people didn't need[0] to know about until today. [0] need is defined here as 'production works without having to know this'.

frankjr 2y ago
It was printing a warning about the deprecation for close to 5 years. I don't think a few more years of support would make much of a difference. > WARNING: Testing via this command is deprecated and will be removed in a future version. Users looking for a generic test entry point independent of test runner are encouraged to use tox. https://github.com/pypa/setuptools/commit/cd84510713ada48bf33d4efa749c2952e3fc1a49 https://github.com/pypa/setuptools/commit/cd84510713ada48bf3...
- baq 2y ago
  Nobody reads these. It’s alert noise. If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.
  - kalaksi 2y ago
    I wouldn't say it's zero cost. It's a risk with potential to cost you. So there's some kind expected value to that cost and the risk grows the longer you ignore the warning
    - baq 2y ago
      I kind of agree - though I make a distinction between risk and cost in the same way you say 'potential cost' i.e. cost is realized risk. Until the risk materializes, you don't pay. The base scenario in this case is the classic thanksgiving turkey though - everything is fine until it isn't.
  - 2y ago

s1mn 2y ago

For those caught out by this, I put together a Github repo that shows how you can work around it in your Github Actions. Hope it helps! https://github.com/simonwhitaker/setuptools-demo https://github.com/simonwhitaker/setuptools-demo

jeroenhd 2y ago

It says a lot about the way this tooling is being used that five years of deprecation warnings still isn't enough to get people to port over their software. Perhaps this should've been implemented as a gradual failure with a temporary workaround ("as of X, this feature will break unless you specify the MY_CODE_WILL_BREAK_IN_OCTOBER=1 environment variable" rather than just breaking after an update), though I doubt that would've changed much.

enriquto 2y ago
Or maybe, you know, just don't knowingly break other people's working code.
- skeledrew 2y ago
  And so never improve the language and ecosystem.
  - enriquto 2y ago
    Linux and Windows keep supporting even blatant bugs for decades, in order not to break old working code that relies on these bugs. The ecosystem keeps evolving healthily under that constraint. Breaking working code for an essentially stylistic change of API is not even malice. It's plain stupidity.
    - skeledrew 2y ago
      An OS isn't touched anywhere near as much by a diverse user base as a language and ecosystem like Python is. It can be more or less guaranteed that everyone building things directly on top of an OS already has a very good idea of what they're doing, and are likely aware of any strange quirks or workarounds they may need to consider. And if they don't, they know how and where to seek help. This is definitely not the case with most Python users, and as such, when bugs and bad practices can be remedied or mitigated they should be, so the many who just want to get their pipeline or automation scripts going can do so without polluting 101 channels with low quality questions and time-wasting problems.

deleted 2y ago

[deleted]

a_cool_username 2y ago

The pypa team are just not capable stewards of core aspects of the python ecosystem. As a maintainer and developer of Python based tools and libraries it is very frustrating having these folks push some change that they want and simply oopsie a significant chunk of the Python ecosystem, and then go dark for hours. They've done it this time by making poor architectural decisions ("Isolated builds should install the newest setuptools") and then add in poor library maintenance decisions ("We'll remove this feature used by thousands of packages that are still in use as active dependencies today"). Possibly each of these decisions were fine in a vacuum, but when you maintain a system that people depend upon like this, you can't simply push this stuff out without thinking about it. And if you do decide to do those things, you can't just merge the code and call it a day without keeping an eye on things and figuring out if you need to yank the package immediately! This isn't rocket science, everyone else developing important libraries in Python world has mostly figured this stuff out. In classic pypa form, it sounds like there was a deprecation warning but it only showed up if you ran the deprecated command explicitly, while the simple presence of this command causes package installs to fail. You have to at least warn on the things that will trigger the error! These days I try to rely on the absolute minimum number of packages possible, in order to minimize my pypi exposure. That's probably good dev practice anyway, but is really disappointing that I can't rely on third party libraries basically at all in Python, when the vast pypi package repository is supposed to be a big selling point of the language. But as a responsible developer I must minimize my pip / setuptools surface area, as it's the most dangerous and unreliable part of the language. Even wrapper tools are not safe, as you see in the thread.

guappa 2y ago
You might want to try getting them from apt-get. They're usually more stable there and get patched if they fail to install or fail to work with a newer version of something else.

skeledrew 2y ago

Looks like Python 2 -> 3 all over again. Something is deprecated for a very long time, people ignore the warning, and then cry foul when the thing is removed. Is there to be no cleanup and advancement in the language/ecosystem?

eesmith 2y ago
As I understand it, the warning was only generated on "python setup.py test", and not on "from setuptools.command import test", which was the deleted module. If you never used 'setup.py test' then the warning was never generated. Pulling up the first repo example I saw in the issue, https://github.com/IBM/python-sdk-core/commits/main/setup.py https://github.com/IBM/python-sdk-core/commits/main/setup.py back in 2019 was created using from setuptools.command.test import test as TestCommand ... class PyTest(TestCommand): ... code to forward to py.test ... setup( ... cmdclass={'test': PyTest}, ...) This was a clear adapter to use setup.py as a test runner, rather than using "pytest". Most likely they all started using "pytest" and forgot that the adapter was there. It wasn't used and never generated warnings. This is confirmed in the commit message from two hours ago at https://github.com/IBM/python-sdk-core/commit/bd44dd1152e01bb381f95e6295103991c0dd9ac4 https://github.com/IBM/python-sdk-core/commit/bd44dd1152e01b... : > That means there will be no more `python setup.py test`, but it wasn't be used for a long time.
- skeledrew 2y ago
  That makes sense. At least they aren't making a fuss about it too, and just did the update to resolve it. I see a setuptools maintainer also did a partial rollback to provide a minimal fix. Hopefully everyone has updated their stuff by the time the minimal fix is also to be removed. Also I fell like this says something important about testing practices. Code should be exercised enough with sufficient coverage, and anything not covered reviewed periodically to see if it can be updated or removed.

justinclift 2y ago

Looks like this was fixed a few hours ago, by the release of a new (patched) version 72.1.0 of setuptools: https://github.com/pypa/setuptools/releases/tag/v72.1.0 https://github.com/pypa/setuptools/releases/tag/v72.1.0