Automatize and modernize deployments #845
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #845 +/- ##
=====================================
- Coverage 53% 53% -1%
=====================================
Files 88 88
Lines 9865 9862 -3
Branches 1846 1845 -1
=====================================
- Hits 5322 5320 -2
Misses 4157 4157
+ Partials 386 385 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Looks good to merge. |
|
Please, let's wait a bit before merging this patch. I'd appreciate to get @itamarst's feedback too, as we discussed this topic together last Friday. |
4383
changed the title
4383
force-pushed
the
4383-patch-1
branch
2 times, most recently
from
f168ceb
to
f0e1422
Compare
4383
commented
Dec 18, 2023
| Source = "https://github.com/eventlet/aiohub" | ||
|
|
||
| [project.optional-dependencies] | ||
| dev = ["black", "isort", "pip-tools", "build", "twine", "pre-commit", "commitizen"] |
There was a problem hiding this comment.
This is optional development dependencies.
If you are ok we that, once major issues will be solved, we could start using pre-commit and migrate to black formatting. Using black would avoid to loose time with formatting issues and pep8...
pyproject.toml
Outdated
| [project] | ||
| name = "eventlet" | ||
| authors = [ | ||
| {name = "Liden Lab", email = "eventletdev@lists.secondlife.com"}, |
There was a problem hiding this comment.
Wonder if we want to update the author, I'm not sure this email address still work and I don't know if someone among us still own access to this inbox, any idea?
Maybe we could create a mailing list to allow user to contact us and then use the address of this mailing list there.
Also I'd suggest replacing the author name by the eventlet orga.
I don't want to hide the previous author, so, we could keep this line in the authors, and, then, just add another line before, to reflect the current maintainers information.
There was a problem hiding this comment.
Per https://community.secondlife.com/forums/topic/455504-sl-educators-mailing-list-disappeared/ lists.secondlife.com was retired in 2020. You might be able to just omit email in those fields?
Looking at https://github.com/eventlet/eventlet/graphs/contributors you can get a list of recent authors (can limit to past 10 years to get more accurate sense).
| run: python -m build | ||
| - name: Publish package | ||
| # deploy only when a new tag is pushed to github | ||
| if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags') |
There was a problem hiding this comment.
publishing on pypi would be allowed only when we push a new tag.
4383
changed the title
4383
force-pushed
the
4383-patch-1
branch
3 times, most recently
from
30df368
to
a819be5
Compare
|
|
4383
force-pushed
the
4383-patch-1
branch
2 times, most recently
from
ec94062
to
1b4ab32
Compare
itamarst
reviewed
Dec 18, 2023
pyproject.toml
Outdated
| Homepage = "https://github.com/eventlet/eventlet" | ||
| History = "https://github.com/eventlet/aiohub/blob/main/NEWS" | ||
| Tracker = "https://github.com/eventlet/eventlet/issues" | ||
| Source = "https://github.com/eventlet/aiohub" |
itamarst
reviewed
Dec 18, 2023
pyproject.toml
Outdated
|
|
||
| [project.urls] | ||
| Homepage = "https://github.com/eventlet/eventlet" | ||
| History = "https://github.com/eventlet/aiohub/blob/main/NEWS" |
|
This all seems fine, other than:
|
|
I guess merging this doesn't actually mean doing a release, and #836 is a blocker for a release, not release infrastructure. So please address and merge, thank you! |
itamarst
approved these changes
Dec 18, 2023
These changes aim to avoid unnecessary workload by automatizing major parts of the release process. With these changes, deployments would be automatic. Pypi will accept new releases coming from eventlet/eventlet by adding a trusted publisher based on OIDC: - https://docs.pypi.org/trusted-publishers/ - https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC) These changes propose: - Manage version number by using git tags rather than manual versioning - Modernize packaging by using pyproject.toml rather than setup.py - Remove old artifacts related to publishing (`bin/release`) - Adding a github workflow dedicated to pypi publish - Added OIDC trusted publisher management https://pypi.org/manage/project/eventlet/settings/publishing/ These changes updated the list of authors to reflect current active core maintainers and allow community members to contact the team. Related to recent discussions: - eventlet#843 - eventlet#842
|
done |
These changes won't release a new version, they are just the machinery. |
|
We are now ready to bring back Python 3.7 at life |
pajod
reviewed
Dec 21, 2023
| @@ -8,71 +8,65 @@ | |||
| DeprecationWarning, | |||
| ) | |||
|
|
|||
| version_info = (0, 33, 3) | |||
| __version__ = '.'.join(map(str, version_info)) | |||
There was a problem hiding this comment.
Dropped intentionally?
Asking because it was still used benoitc/gunicorn#3120
Leaving a reference to https://github.com/maresb/hatch-vcs-footgun-example because hatch docs don't explain the from _version import caveats that well.
There was a problem hiding this comment.
Yes I removed it intentionally.
Now versions are managed by using code version control (git tags).
Version can be retrieved by using pip.
Someone else reported a similar issue yesterday evening, see the discussion there: #842 (comment)
I proposed to reintroduced something like:
from importlib.metadata import version as getversion
__version__ = getversion("eventlet")However, I'd love to understand why gunicorn is checking versions like that and not by using requirements file or dependencies mechanisms. Any idea?
There was a problem hiding this comment.
I'm not gunicorn but speaking from my experience:
Sometimes you need to support multiple versions and modify your behavior based on the version you deal with.
Sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present).
There was a problem hiding this comment.
Sometimes you want to import a package from a development repository tarball you just downloaded (where there's no metadata or Git tags present).
That confirms my choice to not use setuptools_scm or importlib.metadata.version
4383
added a commit
to 4383/eventlet
that referenced
this pull request
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
4383
added a commit
to 4383/eventlet
that referenced
this pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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
that referenced
this pull request
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>
4383
referenced
this pull request
Mar 26, 2024
* Update changelog for version 0.36.0 Related to #940 --------- Co-authored-by: Itamar Turner-Trauring <itamar@itamarst.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These changes aim to avoid unnecessary workload by automatizing major parts of the release process.
With these changes, deployments would be automatic.
Pypi will accept new releases coming from eventlet/eventlet by adding a trusted publisher based on OIDC:
These changes propose:
bin/release)These changes updated the list of authors to reflect current active core maintainers and allow community members to contact the team.
Related to recent discussions: