Moved the metadata from setup.cfg into PEP 621-compliant `pyproject.toml` #2449

KOLANICH · 2022-10-18T18:03:07Z

No description provided.

codecov · 2022-10-18T18:05:37Z

Codecov Report

Merging #2449 (c9a6343) into master (e930d11) will increase coverage by 0.03%.
The diff coverage is n/a.

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

Impacted Files	Coverage Δ
trio/tests/test_ssl.py	`99.86% <0.00%> (+0.55%)`	⬆️
trio/_highlevel_ssl_helpers.py	`100.00% <0.00%> (+11.76%)`	⬆️

newsfragments/2448.feature.rst

KOLANICH · 2022-10-18T23:37:38Z

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 setup.cfg, that is available for ancient versions of setuptools, but is still declarative and machine-parseable. The second commit moves the metadata into pyproject.toml, it has a drawback of a more narrow range of setuptools versions supported. So if someone still has to use the ancient version, he can git revert the second commit.

pyproject.toml

trio/_version.py

njsmith · 2022-10-19T08:15:00Z

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>

KOLANICH · 2022-10-19T09:48:35Z

We want to keep this here because we need to inspect trio.version at runtime. Hatchling supports this.

_version.py file is generated automatically by setuptools_scm

Can't you use pkg_resources.get_distribution("trio").versionfor that?

We can, but it is damn slow.

But this requires making sure it renders well both in GitHub and PyPI.

Checked using https://github.com/pypa/readme_renderer, LGTM.

pquentin

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.

ofek · 2022-10-21T04:35:55Z

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:

There is no concept of package data; files are just files, which makes selection easier to reason about.
The wheel target defaults would do the appropriate thing here.

Additionally, Hatchling:

Supports static analysis tools for editable installations by default whereas the new setuptools does not i.e. it requires enabling an option for IDEs to work.
Uses Git-style glob patterns rather than stdlib globs to better match user expectations.
Allows easy and explicit control of what gets shipped in the sdist target whereas with setuptools it's an objectively confusing mix of conditional wheel options and a MANIFEST.in file.
Hatchling produces a less verbose license section on PyPI because until they support PEP 639 the rendering is not what one may think. It's actually "License: {license_classifier.split(' :: ')[-1]} ({license['text']})" so what you have currently would become License: Apache Software License, MIT License (MIT OR Apache-2.0).

KOLANICH · 2022-10-21T15:54:12Z

hatch_vcs has no write_to.

ofek · 2022-10-21T16:08:40Z

KOLANICH · 2022-10-21T17:33:06Z

thanks for the info, probably the docs about write_to should have the build hook being mentioned.

ofek · 2022-10-21T19:19:31Z

write_to is a setuptools-scm option

KOLANICH · 2022-10-21T21:32:49Z

I mean that hatch-vcs' ReadMe says

The write_to and write_to_template parameters are ignored.

so I propose to write

Use build.hooks.vcs.{version-file,template} instead.

right after that text.

pquentin · 2022-10-22T03:18:39Z

I'd rather continue writing to trio/_version.py manually.

…ct.toml`.

…tools` can change `build-system` section of `pyproject.toml`, the specific config for it was kept.

ofek · 2022-10-25T12:59:42Z

pyproject.toml

+[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"


KOLANICH · 2022-10-25T16:13:18Z

The setuptools-specific code is for the ones who prefer using setuptools over hatchling. It is activated only after patching pyproject.toml.

ofek · 2022-10-25T16:21:14Z

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

ofek · 2022-10-25T16:26:40Z

Oh found it, I didn't realize it was you 😄

webknjaz · 2023-11-03T17:44:53Z

ci.sh

@@ -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


Backends are never needed in outer envs — the frontends automatically provision them in the build venvs.

Suggested change

python -m pip install -U pip hatchling build

python -m pip install -U pip build

webknjaz · 2023-11-03T17:46:17Z

docs/source/releasing.rst

@@ -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


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).

Suggested change

python3 -m build -ws

python3 -m build

webknjaz · 2023-11-03T17:48:30Z

ci.sh

 python -m pip --version

-python setup.py sdist --formats=zip
-python -m pip install dist/*.zip
+python -m build -nsx .


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.

webknjaz · 2023-11-03T17:49:46Z

docs-requirements.txt

@@ -59,6 +59,8 @@ pytz==2022.4
    # via babel
 requests==2.28.1
    # via sphinx
+setuptools-scm==7.0.5 


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.

graingert · 2023-11-04T10:57:23Z

docs/source/.conf.py.kate-swp

this seems like an accidental commit, you should probably add .kate-swp to your global git ignore

graingert · 2024-01-07T20:27:21Z

closing in favour of #2860 which was merged

KOLANICH force-pushed the pyproject.toml branch from 546b86c to a18b735 Compare October 18, 2022 18:12

FasterSpeeding reviewed Oct 18, 2022

View reviewed changes

newsfragments/2448.feature.rst Outdated Show resolved Hide resolved

This was referenced Oct 19, 2022

Move the metadata into PEP 621-compliant pyproject.toml. amoffat/sh#627

Closed

Moved the metadata into machine-readable setup.cfg. #2448

Closed

pquentin reviewed Oct 19, 2022

View reviewed changes

pyproject.toml Outdated Show resolved Hide resolved

pquentin reviewed Oct 19, 2022

View reviewed changes

trio/_version.py Outdated Show resolved Hide resolved

KOLANICH force-pushed the pyproject.toml branch from a18b735 to ffbe7ed Compare October 19, 2022 09:39

KOLANICH force-pushed the pyproject.toml branch 3 times, most recently from fe4b4ce to 18d33bd Compare October 19, 2022 10:27

pquentin requested changes Oct 19, 2022

View reviewed changes

KOLANICH force-pushed the pyproject.toml branch from 18d33bd to 3e8e834 Compare October 19, 2022 12:12

KOLANICH force-pushed the pyproject.toml branch from 3e8e834 to 9e89ff3 Compare October 25, 2022 09:12

KOLANICH added 2 commits October 25, 2022 12:14

Moved the metadata into machine-readable setup.cfg.

2b73902

Moved the metadata from setup.cfg into PEP 621-compliant `pyproje…

7d9f2b8

…ct.toml`.

KOLANICH force-pushed the pyproject.toml branch 2 times, most recently from fb2f2da to 9bafbca Compare October 25, 2022 09:23

Changed the build backend to hatchling. Ones who want to use `setup…

c9a6343

…tools` can change `build-system` section of `pyproject.toml`, the specific config for it was kept.

KOLANICH force-pushed the pyproject.toml branch from 9bafbca to c9a6343 Compare October 25, 2022 09:33

ofek reviewed Oct 25, 2022

View reviewed changes

FasterSpeeding mentioned this pull request Dec 12, 2022

Bump the minimum attrs ver for @frozen #2499

Merged

jakkdl mentioned this pull request Sep 7, 2023

Switch packaging to PDM/Hatch/Poetry #2790

Open

webknjaz reviewed Nov 3, 2023

View reviewed changes

graingert requested changes Nov 4, 2023

View reviewed changes

docs/source/.conf.py.kate-swp

Copy link

Member

graingert Nov 4, 2023

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

graingert closed this Jan 7, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Moved the metadata from setup.cfg into PEP 621-compliant `pyproject.toml` #2449

Moved the metadata from setup.cfg into PEP 621-compliant `pyproject.toml` #2449

KOLANICH commented Oct 18, 2022

codecov bot commented Oct 18, 2022 •

edited

Loading

KOLANICH commented Oct 18, 2022

njsmith commented Oct 19, 2022 via email

KOLANICH commented Oct 19, 2022

pquentin left a comment

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

pquentin commented Oct 22, 2022

ofek Oct 25, 2022

KOLANICH commented Oct 25, 2022

ofek commented Oct 25, 2022

ofek commented Oct 25, 2022

webknjaz Nov 3, 2023

graingert Nov 4, 2023

webknjaz Nov 3, 2023

webknjaz Nov 3, 2023

webknjaz Nov 3, 2023

graingert Nov 4, 2023

graingert commented Jan 7, 2024

	python -m pip install -U pip hatchling build
	python -m pip install -U pip build

Moved the metadata from setup.cfg into PEP 621-compliant pyproject.toml #2449

Moved the metadata from setup.cfg into PEP 621-compliant pyproject.toml #2449

Conversation

KOLANICH commented Oct 18, 2022

codecov bot commented Oct 18, 2022 • edited Loading

Codecov Report

KOLANICH commented Oct 18, 2022

njsmith commented Oct 19, 2022 via email

KOLANICH commented Oct 19, 2022

pquentin left a comment

Choose a reason for hiding this comment

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

ofek commented Oct 21, 2022

KOLANICH commented Oct 21, 2022

pquentin commented Oct 22, 2022

ofek Oct 25, 2022

Choose a reason for hiding this comment

KOLANICH commented Oct 25, 2022

ofek commented Oct 25, 2022

ofek commented Oct 25, 2022

webknjaz Nov 3, 2023

Choose a reason for hiding this comment

graingert Nov 4, 2023

Choose a reason for hiding this comment

webknjaz Nov 3, 2023

Choose a reason for hiding this comment

webknjaz Nov 3, 2023

Choose a reason for hiding this comment

webknjaz Nov 3, 2023

Choose a reason for hiding this comment

graingert Nov 4, 2023

Choose a reason for hiding this comment

graingert commented Jan 7, 2024

Moved the metadata from setup.cfg into PEP 621-compliant `pyproject.toml` #2449

Moved the metadata from setup.cfg into PEP 621-compliant `pyproject.toml` #2449

codecov bot commented Oct 18, 2022 •

edited

Loading