-
Notifications
You must be signed in to change notification settings - Fork 418
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
feat: support PEP 723 run requirements #1100
Conversation
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
a898c2a
to
23bbf01
Compare
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
23bbf01
to
99a90ce
Compare
👋 I would request that y'all hold off on merging this until there's agreement on what exactly the provisional status for the PEP means, in the context of user-facing tooling implementing the described functionality. I've asked about what tooling is supposed to do right now in the acceptance thread for the PEP, because what they're supposed to do seems to be ambigous/unclear to me, and I think we should make the call explicitly to implement something that we might rip out later. |
PEP723 = re.compile( | ||
r"(?m)^# /// (?P<type>[a-zA-Z0-9-]+)$\s(?P<content>(^#(| .*)$\s)+)^# ///$" | ||
) |
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 comment on the regex pattern (and/or maybe using re.VERBOSE
) would be a good idea
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.
I'd say comment as long as we match the PEP's suggested regex.
name = "pyproject" | ||
|
||
# Windows is currently getting un-normalized line endings, so normalize | ||
content = content.replace("\r\n", "\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.
Is this needed? From what I can tell not normalising would simply produce some harmless empty lines that do not match anyway.
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.
If a newline is multiple multiple chars, then it doesn't match the regex. I pre-process this so I can use exactly the regex in the PEP. Another option would be to modify the regex to handle all possible new lines and only that.
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.
(The CI was breaking on Windows otherwise ;) )
To be clear, PEP 722 (rejected) is already implemented in main, and this is just moving that unreleased code to PEP 723 (provisionally accepted). IMO, if this exists at all, it better in the provisionally accepted form rather than the rejected form. |
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
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.
Merged this because I agree here more with @henryiii than the concerns raised by Pradyun. |
docs/changelog.md
Summary of changes
Moved the unreleased feature from the rejected PEP 722 syntax to the (provisionally accepted a few moments ago in python/peps#3505) PEP 723 syntax.
Test plan
Tested by running