-
-
Notifications
You must be signed in to change notification settings - Fork 343
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
Moved the metadata from setup.cfg into PEP 621-compliant pyproject.toml
#2449
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2449 +/- ##
==========================================
+ Coverage 98.96% 99.00% +0.03%
==========================================
Files 117 117
Lines 16119 16119
Branches 3122 3122
==========================================
+ Hits 15952 15958 +6
+ Misses 116 113 -3
+ Partials 51 48 -3
|
546b86c
to
a18b735
Compare
This PR is built on top of an another PR #2448. It is expected that that PR is landed first, and than this one onto that one. The first commit moves the metadata into |
Yeah, it'd be `importlib.metadata` these days (which is in the stdlib since
3.8, and has much less overhead than pkg_resources).
Now that `importlib.metadata` exists, idk how much value it really adds for
us to export `trio.__version__`. We don't use it internally; it's just a
convenience to make it easier to figure out what version of trio you have
installed. I suppose it is a public API though.
…On Wed, Oct 19, 2022 at 1:07 AM Quentin Pradet ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In trio/_version.py
<#2449 (comment)>:
> @@ -1,3 +0,0 @@
-# This file is imported from __init__.py and exec'd from setup.py
-
-__version__ = "0.22.0+dev"
I've had bad experiences in the past with the overhead of pkg_resources
but maybe I didn't use it correctly. It's also semi deprecated in favor of
importlib.
Most importantly, this seems like a complex solution for a problem we
don't currently have.
—
Reply to this email directly, view it on GitHub
<#2449 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEU42HVZQPLMR56ZJH5OKTWD6T2TANCNFSM6AAAAAARIK326Y>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
|
a18b735
to
ffbe7ed
Compare
We can, but it is damn slow.
Checked using https://github.com/pypa/readme_renderer, LGTM. |
fe4b4ce
to
18d33bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are still various references to setup.py left.
Also we want to have a setup.py file to give a clear error because someone will inevitably use it, including GitHub itself: https://github.com/urllib3/urllib3/blob/main/setup.py
And I'm still not convinced setuptools_scm is better than hatchling 🤷 but it's not a huge deal. https://github.com/python-trio/trio/blob/master/docs/source/releasing.rst needs to change though if we're going to use that.
18d33bd
to
3e8e834
Compare
Hatchling maintainer here! I do agree with @pquentin that Hatchling would make things simpler here (and generally speaking too, which is why it's now the default in the official Python packaging tutorial). For example, the following: [tool.setuptools]
include-package-data = true
[tool.setuptools.packages]
find = {namespaces = false} is unnecessary with Hatchling because:
Additionally, Hatchling:
|
|
thanks for the info, probably the docs about |
|
I mean that
so I propose to write
right after that text. |
I'd rather continue writing to trio/_version.py manually. |
3e8e834
to
9e89ff3
Compare
fb2f2da
to
9bafbca
Compare
…tools` can change `build-system` section of `pyproject.toml`, the specific config for it was kept.
9bafbca
to
c9a6343
Compare
[tool.setuptools] | ||
include-package-data = true | ||
|
||
[tool.setuptools.packages] | ||
find = {namespaces = false} | ||
|
||
[tool.setuptools_scm] | ||
write_to = "trio/_version.py" | ||
write_to_template = "__version__ = \"{version}\"\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need
The setuptools-specific code is for the ones who prefer using |
I don't think projects should cater to supposed preferences of alternative build pipelines. I remember something similar from earlier this year, I'll try to find the issue |
Oh found it, I didn't realize it was you 😄 |
@@ -66,11 +66,11 @@ fi | |||
|
|||
python -c "import sys, struct, ssl; print('#' * 70); print('python:', sys.version); print('version_info:', sys.version_info); print('bits:', struct.calcsize('P') * 8); print('openssl:', ssl.OPENSSL_VERSION, ssl.OPENSSL_VERSION_INFO); print('#' * 70)" | |||
|
|||
python -m pip install -U pip setuptools wheel | |||
python -m pip install -U pip hatchling build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backends are never needed in outer envs — the frontends automatically provision them in the build venvs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
python -m pip install -U pip hatchling build | |
python -m pip install -U pip build |
@@ -44,7 +48,7 @@ Things to do for releasing: | |||
* push to PyPI:: | |||
|
|||
git clean -xdf # maybe run 'git clean -xdn' first to see what it will delete | |||
python3 setup.py sdist bdist_wheel | |||
python3 -m build -ws |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not pass both --sdist
and --wheel
, because this causes wheels building from the Git checkout, as opposed to building wheels from sdist (as pip wheel
does).
python3 -m build -ws | |
python3 -m build |
python -m pip --version | ||
|
||
python setup.py sdist --formats=zip | ||
python -m pip install dist/*.zip | ||
python -m build -nsx . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's highly discouraged to use short options with unknown meanings in shell scripts. The typical convention is to use long names so that the readers could know what's happening without having to google or misinterpret things. Also, no need to pass the current dir as it's the default. And two of those options are probably harmful in this case too.
@@ -59,6 +59,8 @@ pytz==2022.4 | |||
# via babel | |||
requests==2.28.1 | |||
# via sphinx | |||
setuptools-scm==7.0.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem needed/related. Also, it's a bad idea to change behavior together with refactoring. If this plugin is needed, it should be integrated separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems like an accidental commit, you should probably add .kate-swp
to your global git ignore
closing in favour of #2860 which was merged |
No description provided.