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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Hatchling build backend #2403
Conversation
pyproject.toml
Outdated
@@ -15,8 +15,7 @@ expand = {"pex_version" = "version"} | |||
|
|||
[project] | |||
name = "pex" | |||
dynamic = ["version"] | |||
requires-python = ">=2.7,<3.13,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*" | |||
dynamic = ["version", "requires-python"] |
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 this is now required I'm not a fan. The intent is to record the real requires-python here in the static metadata and only override in some CI tests when testing out Python 3.X alpha releases. Moving the real metadata to the metadata_hook obscures a bit too much for my liking.
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 issue is that the spec says that tools must adhere to what is defined statically (e.g. they cannot be changed) and Hatchling had a bug that it was not enforcing that.
If you would prefer I can add an option to enable that unsafe behavior but it would be bad for the ecosystem. What do you think?
FYI here is a comment that explains a little bit https://discuss.python.org/t/respecting-core-metadata-2-2-when-building-from-source-distributions/48886/60
It's not exactly related but the bug was revealed during that discussion/thread.
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.
Well, I think PyPA itself is bad for the ecosystem! I'm neck deep in packaging maintaining Pex and I lost patience long ago. I'd rather you not distort your tool for this case and thus continue the trail of tears. Let me step back and consider how to handle this given the thread you pointed to. I won't be back to a keyboard for a few days, but I'll circle back here then and let you know how I'd like to proceed.
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.
Ok, I think I grok the thread you pointed me to. IIUC the criux lies in PEP-621 under https://peps.python.org/pep-0621/#dynamic:
- Build back-ends MUST raise an error if the metadata specifies a field statically as well as being listed in dynamic.
If that were, instead:
* When a field is specified statically as well as marked dynamic, its value must be obtained from the backend dynamic generation process.
All would be well.
@ofek I'll send up a PR and add you as a reviewer that sortof acheives the end I want here using non-canonical fields in pyproject.toml to carry the static metadata / template metadata. That PR may contain comments about the PyPA that you want no association with; so feel free to not comment if you're uncomfortable!
Thanks for hunting down users affected by your rocky release period though, I really appreciate it.
Superseded by #2408 |
Although hatchling fixed a few issues that broke Pex packaging, it has since more strictly adhered to PEP-621 which breaks the existing project metadata customization scheme. Update the scheme to conform to PEP-621 strictures. Also update the tox configuration to work with modern hatchling. Picks up from #2403 by @ofek
Sorry for the trouble back then, 1.22 was a big release 馃槄