Skip to content
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

Closed
wants to merge 4 commits into from
Closed

Update Hatchling build backend #2403

wants to merge 4 commits into from

Conversation

ofek
Copy link
Contributor

@ofek ofek commented May 8, 2024

Sorry for the trouble back then, 1.22 was a big release 馃槄

pyproject.toml Outdated Show resolved Hide resolved
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"]
Copy link
Member

@jsirois jsirois May 8, 2024

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.

Copy link
Contributor Author

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.

Copy link
Member

@jsirois jsirois May 8, 2024

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.

Copy link
Member

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.

@jsirois jsirois mentioned this pull request May 11, 2024
@ofek
Copy link
Contributor Author

ofek commented May 11, 2024

Superseded by #2408

@ofek ofek closed this May 11, 2024
@ofek ofek deleted the patch-1 branch May 11, 2024 17:52
jsirois added a commit that referenced this pull request May 13, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants