eventlet 0.34.1 doesnt work with gunicorn 21.2.0 #3120
Comments
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Fix benoitc/gunicorn#3120 [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
|
Fix proposed eventlet/eventlet#859 |
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Fix benoitc/gunicorn#3120 Also, this patch drop an old python 3.5 remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, rometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 Also, this patch drop an old python 3.5 remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 Also, this patch drop an old python 3.5 remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 Also, update the supported python to 3.7 in a remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 21, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 Also, update the supported python to 3.7 in a remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 22, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 Also, update the supported python to 3.7 in a remaining condition. Python 3.5 is not supported anymore. [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to 4383/eventlet
that referenced
this issue
Dec 22, 2023
Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 [1] benoitc/gunicorn#3120 [2] eventlet#845 [3] eventlet#845 (comment) [4] eventlet#842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example
4383
added a commit
to eventlet/eventlet
that referenced
this issue
Dec 22, 2023
* Generate module version file at build Gunicore rely on `eventlet.__version__` [1], however this data have been removed during our modernization of the continuous deployment mechanisms [2]. People reported problem with gunicore after 0.34.1 [3][4], so, it could be worth to reintroduce similar version info, to avoid side effects. This patch propose to use a `hatch-vcs` hook [5] to generate dynamically, at build, the missing data. Other solutions exists but each of them have their own problems [6]. Indeed, considering "footgun" described in [6] I choose the hatch-vcs approach, because, retrieving a wrong version number during development when the lib is installed in editable mode, is not, I think, something horrible. I prefer this side effect rather than relying on another additional underlying library just to print a version number when eventlet is installed in editable mode. A new additional requirement which would be installed anytime at runtime and production. Moreover, sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present). So, Using `setuptools_scm` or `importlib.metadata.version` won't works in that context. Fix benoitc/gunicorn#3120 _version.py is generated, and therefore shouldn't be checked in. Adding it to `.gitignore`. [1] benoitc/gunicorn#3120 [2] #845 [3] #845 (comment) [4] #842 (comment) [5] https://github.com/ofek/hatch-vcs#build-hook [6] https://github.com/maresb/hatch-vcs-footgun-example --------- Co-authored-by: Itamar Turner-Trauring <itamar@pythonspeed.com>
|
Should be fixed now. |
|
Thanks alot |
|
You are welcome |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When installing
gunicorn[eventlet]==21.2.0it eventually gives an errorAttributeError: module 'eventlet' has no attribute '__version__'when running gunicorn.eventlet==0.34.1has been released on 20th December and it seems to be not compatible withgunicorn==21.2.0The text was updated successfully, but these errors were encountered: