Skip to content

Conversation

@jamie-harness
Copy link
Owner

In pyproject.toml, the baseline requirements for building are supposed
to be listed.

Many end users have a recent enough system-provided ninja, and don't
need to install a new copy into every pandas isolated build virtual
environment. This is handled inside meson-python itself, which
dynamically adds an additional build requirement on ninja via the
backend hook get_requires_for_build_sdist, but only if a suitable
system version is not found.

This is especially helpful on systems where an OS ninja is installed,
but the platform is obscure enough that there are no PyPI "ninja"
wheels, thus forcing pip install pandas to download an additional
copy of the ninja source code and build it via cmake before beginning to
install pandas itself. This is not guaranteed to work...

The ninja entry in various CI or developer-recommended workflows is left
alone because they are opt-in. In such contexts, it may make sense to be
fairly specific about which providers you want to use for any given
dependency, and that's a workflow preference encoded as a workflow build
command. Since it doesn't prevent people from using the baseline
install command, this commit makes no value judgment regarding it.

In pyproject.toml, the baseline requirements for building are supposed
to be listed.

Many end users have a recent enough system-provided ninja, and don't
need to install a new copy into every pandas isolated build virtual
environment. This is handled inside meson-python itself, which
dynamically adds an additional build requirement on ninja via the
backend hook `get_requires_for_build_sdist`, but only if a suitable
system version is not found.

This is especially helpful on systems where an OS ninja is installed,
but the platform is obscure enough that there are no PyPI "ninja"
wheels, thus forcing `pip install pandas` to download an additional
copy of the ninja source code and build it via cmake before beginning to
install pandas itself. This is not guaranteed to work...

The ninja entry in various CI or developer-recommended workflows is left
alone because they are opt-in. In such contexts, it may make sense to be
fairly specific about which providers you want to use for any given
dependency, and that's a workflow preference encoded as a workflow build
command. Since it doesn't prevent people from using the baseline
install command, this commit makes no value judgment regarding it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants