Conda recipe: pip install with meson-python VS meson install

[llohse]

Say, I have a Python project with tightly integrated C++ extensions, which can either by build and installed directly via meson or through mesonpy with pip install.

I am currently writing a conda/rattler-build recipe for said project.

Is there any reason to go through pip and meson-python over calling meson directly?

I see 3 options for the recipe:

1. python -m pip install --no-deps .
2. python -m pip install --no-deps --no-build-isolation .
3. meson setup builddir; meson compile -Cbuilddir; meson install -Cbuilddir

Option 1) installs the build dependencies via pip, which can be seen as undesirable in the conda ecosystem. Options 2) and 3) do not pull these dependencies via pip, so they must be provided by the build environment.

Does meson-python do anything under the hood that justifies the additional complexity of option 2) over option 3)?

[rgommers]

Good question @llohse. For (1) and (2), you don't need the --no-deps --no-build-isolation because conda-build and rattler-build will always enforce that option (see for example https://github.com/prefix-dev/rattler-build/blob/249d98f13c440a8edf0d99d2e0f1208ffca6047e/src/env_vars.rs#L236).

Hence, I recommend a plan python -m pip install ., or (if you prefer pypa/build) something like python -m build -wnx -Cbuild-dir=builddir to build a wheel followed by pip install dist/*.whl. -Cbuild-dir=builddir can be handy for inspection and caching (works with pip as well).

Does meson-python do anything under the hood that justifies the additional complexity of option 2) over option 3)?

Yes, it does. It produces the project's metadata, which (after the wheel gets installed) will be installed into site-packages/pkgname-<version>.dist-info/. This metadata matters for (for example):

• importlib.metadata.version working correctly
• pip and uv being able to tell that your package is installed, so if someone installs some other package that depends on yours then if a conda env already contains your package, pip/uv won't overwrite it with a new one pulled from PyPI.

[llohse]

Thanks for the detailed explanation and recommendation. I have adapted my recipes accordingly.