-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] setuptools version 73.0.0 breaks Pythran #4579
Comments
Thanks for linking the fix, @Avasam. Having taken a look, the conflict arose because
IIUC, a class can only have one metaclass, and when inheriting from multiple classes with different metaclasses, those metaclasses must be compatible (i.e., one must derive from the other). |
@jaraco If you feel like reverting my change for a quick fix, go ahead. It didn't intend to cause metaclass issues. Otherwise a PR should already be ready: #4580 @agriyakhetarpal Yep, that's what I found as well through my investigation. Thanks for the easy reproducer. No change should be needed from Pythran |
Thank you for the speedy fix! I don't know if you can keep something like Edit: or maybe it is better to not over-complicate things, and the issue has now been closed just as I edited my comment 😅 |
Unfortunately not (and I just tested all 3 locally just to validate what I'm saying is true).
|
Thanks for the explanation, @Avasam! |
@agriyakhetarpal , adding a metaclass and trying to combine it with an already existing class hierarchy that is part of a 3rd party package sounds like a very fragile approach and prone to errors. I don't know if that could work, but something a bit more flexible would be: class PythranBuildExtMeta(type(Command)):
... But I haven't tested, and I don't know if that would work. If that works, maybe it would give us the chance to re-revert back to ABC in a future release... |
Yes, @abravalheri, that makes sense. I was trying to do something similar to yours in serge-sans-paille/pythran#2230, copying over the diff from there: class PythranBuildExtMeta(type(LegacyBuildExt)):
def __getitem__(self, base):
return type(
'PythranBuildExt', (PythranBuildExtMixIn, base), {}) to work around the conflict, where Note: not an expert on metaclasses, so I could, of course, be wrong with my experiments 😄 |
If that works, that could be a more stable/preferred long-term solution, and the PR would be worth pursuing even after the patch that @Avasam provided. |
Seems like, as with most scenarios where people tried to do anything complex with setuptools, it originated back when the class hierarchy was "distutils from the stdlib", so that may be a bit more forgivable... :) |
Hi there, SetupTools v73.0.1 breaking the library "textract", when trying to install textract ,on the building dependencies stage it breaks for setuptools to use the latest hash value and instead it is picking up the old hash value. Tried installing SetupTools using wheel file the latest version is breaking, although 71.1.0 is installing perfectly fine. |
This relates to same issue i guess, Anyone has any luck installing setupTools v73.0.1? |
Hi @Kartikchauhan12, could you please submit a new issue following the bugs form? |
setuptools version
setuptools==73.0.0 (latest released version available on PyPI)
Python version
All supported ones
OS
any
Additional environment information
This currently occurs with the latest release of Pythran (version 0.16.1 as released on PyPI on 28/05/2024), and older versions have not been checked against.
Description
Hi there! The latest release of
setuptools
currently breaks SciPy' builds (scipy/scipy#21416) and, in turn, SciPy's recipe in Pyodide (pyodide/pyodide#5018) because SciPy now uses Pythran as a required dependency for transpiling Python to C++ (as reported in serge-sans-paille/pythran#2228).The truncated output from Pythran is as follows – detailed output(s) below:
I have bisected the problem between the v72.2.0 and v73.3.0 tags as reported in scipy/scipy#21416 (comment), and the breakage seems to be coming from #4503 (i.e., f9398b1). I have opened this issue for visibility while I continue to investigate the problem at the time of writing.
Also, please refer to @rgommers's comments in serge-sans-paille/pythran#2228 (comment) that describe the situation in context to SciPy.
Expected behavior
The expected behaviour is that Pythran works and can be used to compile extension modules, whether for SciPy or elsewhere for all recent-enough versions of
setuptools
, sincesetuptools
is a dependency of Pythran.A workaround for this is available via serge-sans-paille/pythran#2229 which pins
setuptools
to <73, and I have another hotfix ready at serge-sans-paille/pythran#2230 which passes the tests.How to Reproduce
Here is a minimal reproduction script:
Output
The text was updated successfully, but these errors were encountered: