Compatibility with uv and relative imports

[serjflint]

What's the problem this feature will solve?

Hi! I searched for related issues and found none.

I am trying to make a setup.py which works with both pip and uv. But I have a relative import which can be worked around in different ways for pip and uv. More at astral-sh/uv#2635

I wish for more straightforward interop and I believe the asked feature would help pip itself.

Describe the solution you'd like

To set the PROJECT_ROOT variable automatically before evaluation setup.py or support relative imports without https://peps.python.org/pep-0440/#direct-references

Alternative Solutions

I have a workaround but it has a condition based on an undocumented feature of uv.
See astral-sh/uv#2635

Additional context

I can try to make a pull request if you are ok with one of the solutions.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

Package metadata (install_requires) can't be relative to the source directory, because there is no reason to assume that the wheel built from the source will know where the source is located (the source may not even be available) at the time when the wheel is installed.

You would be better building the 2 projects independently, and then installing them from wheels, with the dependency being given using the dependency name, rather than with a path.

[serjflint]

Package metadata (install_requires) can't be relative to the source directory, because there is no reason to assume that the wheel built from the source will know where the source is located (the source may not even be available) at the time when the wheel is installed.

You would be better building the 2 projects independently, and then installing them from wheels, with the dependency being given using the dependency name, rather than with a path.

Yes, I agree. That is the right way. I can see how relative imports may be harmful.

But for historical reason we have a logically single package which is split between local directories. If it is ok Is it possible at least set PROJECT_ROOT variable?

P.S.: after some trial and error we got a working solution with an absolute path astral-sh/uv#2635 (comment)

[uranusjr]

SUpporting this in package metadata does not sound right to me. It makes sense if the package is installed in the specific way you described, but the format is also used in other scenarios, e.g. when the metadata is packaged into an sdist or wheel—arguably the main use case_—where the feature would not only not make sense, but produce either confusing or bad results. It would be preferrable to me if this is only allowed specifically for things that can’t be packaged into those formats. See #8828 (which unfortunately I failed to carry out).

[pfmoore]

If it is ok Is it possible at least set PROJECT_ROOT variable?

No, because if we did that people would rely on it for all sorts of things (that we can't necessarily anticipate). And given that we're talking about having that environment variable in the published metadata of a wheel, this could cause problems in all sorts of other contexts.

Why does uv set PROJECT_ROOT anyway? As far as I'm aware, it's not a documented standard, and I couldn't even find it mentioned in the uv readme (uv doesn't have formal docs yet, as far as I am aware).

[serjflint]

Why does uv set PROJECT_ROOT anyway? As far as I'm aware, it's not a documented standard, and I couldn't even find it mentioned in the uv readme (uv doesn't have formal docs yet, as far as I am aware).

I found its usage in some issue
astral-sh/uv#1626 (comment)

After blaming the code I found a commit which references other tools
astral-sh/uv#640
and pip
astral-sh/uv#592 (comment)

[pfmoore]

OK, I don't think pip will support this unless it becomes a standard (and personally, I don't think a proposal to standardise it would succeed, but that's a separate matter).

[uranusjr]

I would add that uv’s reimplementation on pip’s environment variable expansion seems to not be exactly feature-compatible. As far as I am aware, pip only expands environment variables in requirements and constraints files (which req_file.py handles), but uv seems to implement this for all PEP 508-compatible URLs (from my understanding to astral-sh/uv#640). This is wrong.