Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify options for meson in pyproject.toml #108

Closed
llohse opened this issue Jul 22, 2022 · 6 comments
Closed

Specify options for meson in pyproject.toml #108

llohse opened this issue Jul 22, 2022 · 6 comments
Labels
enhancement New feature or request

Comments

@llohse
Copy link

llohse commented Jul 22, 2022

Is it possible to specify options for meson in the pyproject.toml? If yes, could you document how?

Consider a project that has optional python bindings. I would need to enable them, when building via pip / pypa build.
mesonpep517 has meson-options that get passed to the meson call, but I could not find anything comparable in meson-python.

@rgommers
Copy link
Contributor

That does sound like a reasonable feature request to me. It's not possible right now to do this in pyproject.toml; there is no meson-python specific section there.

xref mesonpep517 docs: https://thiblahute.gitlab.io/mesonpep517/pyproject.html#mesonoptions

@rgommers
Copy link
Contributor

rgommers commented Sep 2, 2022

Based on ufo-kit/ufo-core#189 (comment), I think this doesn't necessarily need to live in pyproject.toml. If it's a default option, then it can live in meson.build files. If it's not default but a user-specific customization, then it should not be done via editing pyproject.toml but via the CLI interface similar to the mesonpep517 link above. The latter is covered by gh-122.

@llohse does that work for you?

@llohse
Copy link
Author

llohse commented Sep 2, 2022

Mhm, not really. What I have in mind is rather a convenience feature as follows.
An option that is not default when building the project (via meson) but is default when building it via pep517.

For example, consider a C/C++ library with optional python bindings. When installing the library via pep517, it would not make sense to compile it without the python bindings.
Always having to call pip install package --build-option="--with-python" is be rather inconvenient and forcing the package to build the python bindings by default also might not always be what you want.

It might be possible to implement this in meson.build by somehow detecting when being called by meson-python (although I would not know how) but I am not sure if that would be any cleaner.

@rgommers
Copy link
Contributor

rgommers commented Sep 3, 2022

Ah okay, thanks for the clarification. It's clear to me now. So gh-122 is a prerequisite, but this makes sense as a follow-up. The interface should follow whatever comes out of gh-122. Something like

[tool.meson-python]
setup-args = "-Doption=value"
install-args = "-Dother-option=other-value"

It might be possible to implement this in meson.build by somehow detecting when being called by meson-python (although I would not know how) but I am not sure if that would be any cleaner.

No, that seems worse. meson should not know at all who is calling it, only what arguments are passed to it.

@eli-schwartz
Copy link
Member

It might be possible to implement this in meson.build by somehow detecting when being called by meson-python (although I would not know how) but I am not sure if that would be any cleaner.

If you wanted to implement this, it would have to be for example using a run_command() that launches a script which in turn uses something like psutil to check the parent process of the parent process (Meson) of the current one (custom script), and see if its name or full command line suggests that it is pip or python -m build or something else indicating Meson is not being run standalone. This should tell you how clean it would be. :D

@dnicolodi
Copy link
Member

Fixed in #167.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants