-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Move to metadata to pyproject.toml
#166
Conversation
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.
Thank you very much for working on this @di.
From my perspective it looks very good (I just added very minor comments).
I also validated the file with validate-pyproject
and everything is in shape!
It would be nice though, if possible, to wait at least until the feature stabilises a bit. I think I manage to cover most of unexpected issues in 61.1.1 (there are some very edge-cases left) but we never know... Maybe some users will find other bugs in the following weeks.
pyproject.toml
Outdated
"Source" = "https://github.com/pypa/sampleproject/" | ||
|
||
# To provide executable scripts, use entry points in preference to the | ||
# "scripts" keyword. Entry points provide cross-platform support and allow |
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.
To avoid confusion with project.scripts
, setuptools uses tool.setuptools.script-files
for the legacy kind of script (which is explicitly deprecated in the docs now).
Maybe we can just skip this advice for the sake of avoiding confusion?
PEP 621 splits general entry-points, console_scripts
and gui_scripts
in 3 separated fields. There is a chance the wording entry point might be confusing when referring to scripts
for new pacakgers.
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.
Yes, this whole comment needs either re-wording or removing.
We shouldn't be mentioning the setuptools-specific "scripts" keyword at all here.
Regarding |
I think I'm OK with removing it entirely from this sample regardless. I feel like overall this is an anti-pattern that we probably don't want to be encouraging for the average use case. |
Edit: resolved by using the tox4 pre-release. |
pypa/setuptools#2816 is now resolved, so moving this out of draft status. |
@di is there anything else blocking this PR? Will this only be landed after setuptools removes the "beta" banner or is it good to land already? |
I think I was waiting to not have to require the Some reviews/approvals on this would be good as well. |
@gaborbernat do you have an ETA for having a final release of tox 4? |
No promises. I'm currently blocked by health issues, so probably not this year (assuming no one else picks up development of tox 4). |
Could you restore the |
Just to set expectations here: I'm not planning to revisit this PR until:
|
I’m not sure I understand why you want to omit the build system table and therefore block yourself on tox.
|
PEP 518 explicitly says that "Tools should not require the existence of the Since this repo is intended to be an example/template for people completely unfamiliar with Python packaging (including the intricacies of PEP 517/518) in my opinion we should minimize the amount of unnecessary boilerplate if at all possible. |
Given that we currently have a I should also note that PEP 517 notes:
In particular, this means that the legacy setuptools backend will be used in the absence of |
Fair points @pfmoore. I think all outstanding comments/suggestions have been resolved. |
Well, I'll also note that the provision in PEP 518 as I understand it was added to ease the transition, not to elevate setuptools above other backends; the recommendation for new projects has been to include it. In addition, omitting the build system table subtly changes the behaviour of setuptools, placing the project root on the Python path. |
Who can approve this PR? |
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.
A few comments related to making this PR be solely about moving metadata into pyproject.toml
. Can the unrelated changes be moved to their own PR(s), please?
Does #181 help? It gets rid of the various deprecated features that are causing a lot of the debate here. |
Co-authored-by: layday <[email protected]>
I've fixed up this PR after merging #181 into main. Hope I did it right! |
It feels a bit off to merge based on my own approval, so @di I'll wait for your OK (or you can merge if you're happy). |
Hmm, we may have conflicted here. @di I think your force-push blew away some changes I made :-( |
Oops, sorry @pfmoore, I didn't see your changes here before I rebased on main! |
@pfmoore I think I restored all your changes here, if it looks good to you, please merge! |
No worries, I normally do PRs from my own fork, messing about with branches in the main repo is new to me so I didn't know the protocols :-) |
Looks good to me. I'd dropped the I'll merge this once checks are complete. |
lol looks like they completed while I was typing that! |
@@ -1,4 +0,0 @@ | |||
[metadata] |
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.
FTR this broke the linkcheck in PyPUG
Now that PEP 621 support has been merged in pypa/setuptools#2970, we can move project metadata into
pyproject.toml
and get rid ofsetup.py
andsetup.cfg
.The one 'regression' is that external data files are deprecated (https://setuptools.pypa.io/en/latest/userguide/datafiles.html) so support has been removed here.
This should remain a draft PR until pypa/setuptools#2816 is resolved and editable installs work.
Closes #56, closes #57, closes #96.