PEP 739 and cross compiling

[virtuald]

Currently, I don't believe this project would be usable in a situation where you were cross-compiling via PEP 739 information alone. The following would be needed:

1. Need to install wheels that you depend on in some virtual environment
2. pkgconf needs to be able to look up entry points in that virtual environment while presumably executing outside of that environment

Assuming that (1) was doable (seems like uv might be able to partially do this: astral-sh/uv#7957), I'm not sure what we need to accomplish (2). I guess importlib_metadata would need an API to allow it to inspect an environment that is not the current running environment, or trick it into doing so.

Of course, both 1 and 2 are provided by crossenv without PEP 739 even though getting crossenv to work is a bit fiddly.

I note that PEP 739 says:

Information specific to a Python environment, such as the site-packages path, is outside the scope for this file, and the PEP authors expect that a static environment description file will be introduced via a future PEP.

So probably this isn't really doable without that future PEP (which should hopefully make it so that you can find entry points in another venv).

I don't think this is a really high priority thing to work on since crossenv exists and works fine (even if it's a bit fiddly), just noting this so I don't forget it in the future.

[rgommers]

I'm not sure what we need to accomplish (2). I guess importlib_metadata would need an API to allow it to inspect an environment that is not the current running environment, or trick it into doing so.

I'm afraid that this isn't doable in general, because the entrypoint executes code that is part of the package, and that may trigger import of non-native extension modules.

I think the long term direction is to try and standardize the location of .pc files so they can be accessed without running any code. If that were to happen, then it's a matter of prepending to PKG_CONFIG_DIR for things to work.

[virtuald]

I'm afraid that this isn't doable in general, because the entrypoint executes code that is part of the package, and that may trigger import of non-native extension modules.

I agree that it's not doable in general, but it might be doable if we constrain the problem.