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.