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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Context formatting of project.dependencies is not standard compliant? #1331

Open
sbidoul opened this issue Mar 17, 2024 · 7 comments
Open

Context formatting of project.dependencies is not standard compliant? #1331

sbidoul opened this issue Mar 17, 2024 · 7 comments

Comments

@sbidoul
Copy link
Member

sbidoul commented Mar 17, 2024

It seems that hatchling supports context formatting in project.dependencies or project.optional_dependencies, so resulting metadata in the built artifacts differs from what is specified in pyproject.toml.

However, the pyproject.toml spec says: A build back-end MUST honour statically-specified metadata (which means the metadata did not list the key in dynamic)..

So it seems that hatchling is deviating from the spec in this respect?

This is potentially problematic as some tools may rely on metadata in pyproject.toml being static as an optimization to bypass a potentially costly PEP 517 metadata preparation step. For instance this kind optimization is considered for implementation of pip install --only-deps.

What do you think?

@ofek
Copy link
Collaborator

ofek commented Mar 17, 2024

My instinct is to close this because it's up to the user whether or not they require such features and therefore may not be compliant with the spec i.e. users who do not absolutely require this functionality will necessarily not use it. UV just added support for this use case: astral-sh/uv#2475 (comment)

If you want, I could add a warning in the documentation?

@sbidoul
Copy link
Member Author

sbidoul commented Mar 17, 2024

I personally think deviating from standards is dangerous and has the potential to create a lot of confusion.

uv worked around it in one case, but for instance uv pip compile pyproject.toml still fails in with such a project as it reads project.dependencies without bulding.

So I guess, yes, calling that out the documentation as a warning would be a good step.

@ofek
Copy link
Collaborator

ofek commented Mar 17, 2024

Okay, how does this sound: when Hatch introduces workspaces (which would be what users actually want) then I will change the functionality in Hatchling to be such that an option would be required to enable context formatting on static fields. There are other options like that: https://hatch.pypa.io/latest/config/metadata/#allowing-direct-references

@ofek
Copy link
Collaborator

ofek commented Mar 17, 2024

Actually wait, that is the current behavior because Hatchling will by default error for direct references such as local paths. So back to the beginning I suppose all I can do is add a warning because this is already doubly opt-in: once for usage and then enabling the option to make usage work.

@charliermarsh
Copy link
Contributor

I suspect uv pip compile pyproject.toml will continue to fail here even once we add support for PEP 517 hooks there, because we'll still want to read metadata directly from the pyproject.toml when we can.

@ofek
Copy link
Collaborator

ofek commented Mar 21, 2024

I don't know how to make the situation better than a doubly opt-in option. I could of course remove the feature but then there are users that require it.

@hauntsaninja
Copy link

This seems like a pretty straightforward violation of the standards to me. Hatch should have enforced use of dynamic and put the extra information elsewhere, or not used PEP 621. (Or Hatch should swallow the world and provide its own frontend / locking / etc)

Note there is one standards violating thing Hatch could do that would help. Which is, Hatch could still enforce that you have to declare dynamic = ["dependencies"], but not enforce the following part of PEP 621:

A build back-end MUST raise an error if the metadata specifies the name in dynamic.

This means that anything checking dynamic to determine whether it can skip build backend invocation would still work. For instance, jazzband/pip-tools#1964

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

No branches or pull requests

4 participants