Move the metadata into PEP 621-compliant pyproject.toml.

[KOLANICH]

No description provided.

[amoffat]

Hi there. This might be done already on the 2.0 branch. Please rebase off of that branch and see if there is a diff

…

On Tue, Oct 18, 2022, 11:36 AM KOLANICH ***@***.***> wrote: ------------------------------ You can view, comment on, or merge this pull request online at: #627 Commit Summary - 1e4da5c <1e4da5c> Move the metadata into `setup.cfg` - 9503714 <9503714> Move the metadata into `PEP 621`-compliant `pyproject.toml`. File Changes (4 files <https://github.com/amoffat/sh/pull/627/files>) - *M* .github/workflows/run-tests.yml <https://github.com/amoffat/sh/pull/627/files#diff-7314d0ebbd2e9537ae4889316745b4fd2fa43cb86275c9caae18a86ba228b642> (6) - *A* pyproject.toml <https://github.com/amoffat/sh/pull/627/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711> (57) - *D* setup.cfg <https://github.com/amoffat/sh/pull/627/files#diff-fa602a8a75dc9dcc92261bac5f533c2a85e34fcceaff63b3a3a81d9acde2fc52> (8) - *D* setup.py <https://github.com/amoffat/sh/pull/627/files#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7> (59) Patch Links: - https://github.com/amoffat/sh/pull/627.patch - https://github.com/amoffat/sh/pull/627.diff — Reply to this email directly, view it on GitHub <#627>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7IKNC5HJRNTMRCDWHHNLWD3UZ5ANCNFSM6AAAAAARILWASY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[KOLANICH]

2.0 branch

1. uses poetry, that doesn't support PEP 621
2. is stale.

[amoffat]

Poetry will eventually support PEP 621, and I am not currently interested in switching from poetry on the 2.0 branch unless there is a very compelling reason. I think that makes this PR premature, do you agree?

[KOLANICH]

I think that makes this PR premature, do you agree?

I disaggree. I'm interested in getting the metadata in PEP 621 format (or at least in having PEP 517-compliant pyproject.toml + setup.cfg or any other declarative metadata format that can be easily and reliably parsed) right in the default branch because I am creating a package manager for python replacing pip for some use cases (it installs bleeding-edge packages from GitHub repos of projects), and that package manager relies on PEP 517 for detection of build backend and for building packages and on machine-parseable metainformation being available within source distribution (and setup.py is not considered a machine-parseable format, well, it can be parsed for some cases, but it is additional complexity on the tool side and noone can guarantee that the parsing is correct, a better alternative is to switch the packages to the state-of-the-art declarative metadata format). So I move dependencies of my packages, that are not already using the declarative metadata format, to PEP 621, one-by-one.

[amoffat]

What do you propose we do with poetry on the 2.0 branch? since it will eventually be merged into default branch, it will undo any of your proposed changes.

[pquentin]

I came here because I received similar pull requests in projects I maintain (urllib3/urllib3#2299, python-trio/trio#2448, python-trio/trio#2449) and while I understand your goals @KOLANICH, you're not very reasonable because you don't care about the goals of the projects you're contributing to. Also, opening a pull request is one thing, but making sure that the resulting sdist and wheels are the same and fixing any issues that come up are another thing.

I'm sure you'll find this story very educational: https://nitter.it/di_codes/status/1542489151630712832

[KOLANICH]

What do you propose we do with poetry on the 2.0 branch?

This decision is not up to me, but up to the maintainers.

since it will eventually be merged into default branch

That branch is stale:

Updated Oct 13, 2021 by ecederstrand

, so there is no certainty (for me) that it will be merged in near future and, TBH, that it will be merged at all.

There is a choice:

1. keep PEP 621 metadata, keep setuptools
2. change the backend to something else (flit_core, hatchling), keep PEP 621 metadata
3. change the backend to poetry, keep the PEP 621 metadata - only makes sense if poetry implements PEP 621
4. replace the file with the one from release/v2.0.0 branch, switching to poetry and converting the metadata into poetry-specific format

I'm OK witn any of them: in all of them the metadata format is declarative and my tool has metadata parsing backends implemented for all flit, poetry, hatchling and setuptools.

I consider the options 1 and 2 the most beneficial since the metadata format used in them is the standardized PEP 621. I consider the option 1 the most beneficial since recently speed of setuptools has improved (I have not measured, just got surprized how fast it has started to work after I have updated it).

it will undo any of your proposed changes.

No problem. Closing a PR will also "undo" them. The most of conversion was automatic using setuptools_py2cfg and ini2toml tools, the manual part of work was to check whether everything looks OK after the conversion, to restore the info stripped by the tools and to fix CI scripts.

@pquentin

I'm sure you'll find this story very educational: https://nitter.it/di_codes/status/1542489151630712832

Thanks for the story (I also use libredirect BTW), I enjoyed it. Well, I have considered some of the points described there. For example it could be possible to create a bot mass-converting packages and mass-sending PRs, but it would be very hard to do it with enough quality fully automatically, that's why I do it semi-automatically - the conversion is done automatically, then human-vetted and postprocessed.

while I understand your goals @KOLANICH, you're not very reasonable because you don't care about the goals of the projects you're contributing to.

Everyone cares about own issues, but it turnes out that in a lot of cases solving an issue of one person solves an issue of other ones too. Yes, I have implemented those PRs out of self-interest, but I consider them beneficial to the projects they are sent to because the PRs improve the projects' compatibility to the tools and because it is a step to improve security of the ones installing them (in setuptools repo one can find an issue (https://github.com/pypa/setuptools/issues/2901) about making setup.py-based package building an explicit opt-in and about making package building using PEP 517 backends secure). Purpose of projects is to solve issues of their users that are within scope of projects, and if a project has files for packaging, then packaging-related issues are within the scope of the project.

Also, opening a pull request is one thing, but making sure that the resulting sdist and wheels are the same and fixing any issues that come up are another thing.

I will check it (and I usually currently rely on CI for detecting issues). Though please keep in mind, I don't think the wheels and sdists should be exactly the same to the ones generated by the old variant with setup.py. For example in the most of the PRs I switch to using setuptools-scm for fetching versions automatically, and it adds git commit tag to versions (it can be disabled, but I think it is a beneficial feature). Or when auto-generating version file I strip the unneeded minor parts: the template has to go into pyproject.toml and adding the comment there is just unneeded bloat. But if, for example, tests go into the wheel, if they didn't (or just shouldn't go there), then it should be solved.

[amoffat]

Thanks for the context. After careful consideration, I think we will continue down the poetry path. Please contact the poetry team if you wish to advance PEP-621 there, as I believe it will be a better use of everyone's energy. Here's a good starting point python-poetry/roadmap#3