Added support for tool.meson-python.env table in pyproject.toml

[tobiasdiez]

Adds an env table as config option in the users pyproject.toml. Those environment variables are used for all Meson/Ninja subprocesses.

This makes it possible to set a reproducible set of env variables accross all builds (inital + editable rebuild). In my case, this was triggered by the desire to set FORCE_PKGCONF_PYPI.

[dnicolodi]

Why doesn't setting the PKG_CONFIG env var when building the editable package to pkgconf-pypi suffice for your use case? As far as I can tell, the effect of FORCE_PKGCONF_PYPI is to make pkgconf behave like pkgconf-pypi. AFAIK, Meson should remember which pkg-config it used during the initial setup and use the same if it needs to reconfigure. You may also use a native or cross file to specify which pkg-config executable to use.

[eli-schwartz]

Setting this in pyproject.toml implies that anyone who wants to use a different value must edit a source-controlled file, which feels a bit dubious.

[tobiasdiez]

Why doesn't setting the PKG_CONFIG env var when building the editable package to pkgconf-pypi suffice for your use case?

Since in some settings pkgconfig-pypi is not installed. I only want it to behave like pkgconf if its installed in the venv.

Setting this in pyproject.toml implies that anyone who wants to use a different value must edit a source-controlled file, which feels a bit dubious.

Sure, you don't want to use it to set env variables that users/other devs likely need to modify. In this aspect, it's similar to the other meson config options that can be specified in pyproject.toml. I was also wondering if the pyproject-specfied env variables or the user-set variables should have priority.

[dnicolodi]

I don't understand what you are trying to achieve. One one hand you say that using pkgconf-pypi (or pkgconf with the FORCE_PKGCONF_PYPI env var set) is not a prerequisite for building the package. On the other hand you want to encode the use of pkgconf-pypi in the package metadata, forcing all builds of the package to use pkgconf-pypi or to have to edit the package metadata to build it.

In general, encoding setup-specific configuration in the package metadata is not the right thing to do. And here it seems that you want to do precisely that. If in your setup you need to use pkgconf-pypi you should do something like:

$ uv venv
$ uv pip install pkgconf
$ PKG_CONFIG=pkgconf-pypi uv pip install -e .

Which, by the way, judging from the documentation, seems to be the recommended way to run pkgconf with the Python integration layer.

[rgommers]

I think I understand the motivation, however I agree that adding a meson-python tool setting to set environment variables related to another package is a bit of an anti-pattern. The use case is real, but the answer is probably to address this in pkgconf-pypi, maybe splitting that package in two so you can explicitly depend on pkgconf-pypi and it'd have the behavior you want without any env var needing to be set.

I also checked scikit-build-core to see if it had a tool option like this, given that it has a ton of settings to play with (unlike meson-python, it errs on the "more is better" side of config option). It doesn't have this feature though. I also can't think of other use cases that would not be better solved some other way.

[tobiasdiez]

I don't understand what you are trying to achieve.

I would like to have both of these scenarios work and use the system-provided dependencies:

With pkgconf-pypi installed in the build venv:

$ uv venv
$ uv pip install pkgconf
$ uv pip install -e . --no-build-isolation

Without pgkconfig-pypi installed in the build venv:

$ uv venv
$ uv pip install -e .  --no-build-isolation

Sure, I can manually set PKG_CONFIG or FORCE_PKGCONF_PYPI in the first case, but then I have to remember what I installed in that particular venv etc. With this PR, I could simply set FORCE_PKGCONF_PYPI in the pyproject.toml env table, and both of the above steps would work seamlessly.

For more details: the main package doesn't have any build requirement on pkgconf-pypi, but one of the tests is using it. So depending on whether the dev/test group is installed in the venv, the build of the main package is failing.

The use case is real, but the answer is probably to address this in pkgconf-pypi, maybe splitting that package in two so you can explicitly depend on pkgconf-pypi and it'd have the behavior you want without any env var needing to be set.

A change in behavior in pkgconf-pypi would of course also address my issue, although I don't quite see how splitting the package would help.

I also checked scikit-build-core to see if it had a tool option like this, given that it has a ton of settings to play with (unlike meson-python, it errs on the "more is better" side of config option). It doesn't have this feature though. I also can't think of other use cases that would not be better solved some other way.

I agree that there are not too many use cases. It would be helpful for external tools that are most conveniently controlled via env variables, or perhaps as a more streamlined interface to set different defaults for meson build options. Perhaps the closet feature in other projects is setenv in tox.

[rgommers]

A change in behavior in pkgconf-pypi would of course also address my issue, although I don't quite see how splitting the package would help.

Well, there's two "modes" for the pkgconf binary that gets installed:

1. A plain build of pkgconf, no special magic (now default)
2. A mode where one enables awareness of Python envs (what you're trying to enable)

Due to how build isolation works, it's not possible for pkgconf to do the right thing automagically in all situations with build isolation turned either on or off. For dev workflows you tend to want (2), for building wheels with cibuildwheel you tend to want (1).

You only want (2), so a new package that gives you a pkgconf binary with mode (2) will address the problem. In your test suite usage, you'd never need (1).

[tobiasdiez]

I think my problem is more that in case (1) pkg-config is not able to find system dependencies. I've opened pypackaging-native/pkgconf-pypi#110 to track this.

Closing as I got the impression there is no desire to add the env table to meson-python.

[rgommers]

Thanks @tobiasdiez! I'll follow up on pkgconf-pypi.