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

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

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

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

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

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

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

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

* 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 <[email protected]>

* Update changelog for version 0.36.0

Related to #940

---------

Co-authored-by: Itamar Turner-Trauring <[email protected]>