-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
celery 5.2.3 fails to install due to requiring newer setuptools #1280
Comments
Hi! Thank you for reporting this :-) So I'd love to be able to update to the latest (or even, any newer) setuptools, however setuptools v58.0.0 included a breaking change that affects some packages (see the number of ping-backs in the issue history from other projects having to apply fixes): Whilst the number of affected packages is only a minority in the ecosystem, at cloud-scale that's still potentially hundreds/thousands of apps. We'll obviously need to update setuptools at some point, however only once the tipping point of cost (gradually decreasing number of affected packages + people updating their app's deps to the fixed versions) is outweighed by the benefits (an increasing number of packages that only work on newer setuptools). In the meantime, the setuptools version can be overridden if needed, by adding a setuptools version to However looking at this Celery error specifically, it seems that they don't actually rely on any newer setuptools features, and that the version range made more restrictive than perhaps they intended (it only needed to set an upper version bound, but set a very restrictive lower bound too). (The setuptools version change was made in Celery v5.2.3 in celery/kombu#1466, in order to work around issues with setuptools 59.8.0+ pypa/setuptools#2936). I was going to file an issue asking Celery to widen the version range, however in the last few days they've already adjusted it, in: See also: It looks like that fix will be in the next Celery release (presumably v5.2.4). With that release, Celery will work with the setuptools version used by this buildpack again, and I haven't heard of any other packages needing newer setuptools - so we're still best staying put on the existing setuptools version for now :-) |
This change has been done following the example from [1] This seeks to resolve the need for kombu to return valid whislt using use_2to3 a dependency of setuptools[2]. [1] https://github.com/celery/kombu/pull/1466/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR21 [2] heroku/heroku-buildpack-python#1280
This change has been done following the example from [1] This seeks to resolve the need for kombu to return valid whislt using use_2to3 a dependency of setuptools[2]. [1] https://github.com/celery/kombu/pull/1466/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133ddR21 [2] heroku/heroku-buildpack-python#1280
Hey folks,
This is in the exact same spirit as issue #949
Here's what we're seeing when deploying:
Can we bump the setuptools version to be >=59.1.1 or is there other reccomended way to handle this?
The text was updated successfully, but these errors were encountered: