Pass the kind of build (regular/editable) to meson

[lithomas1]

This is useful for pandas, where we would not want to install conftest.py (would break pytest due to multiple conftest.py!) on an editable install, but would want to do it on a release build(we have a function pandas.test() that allows users to test their pandas in the public API).

[rgommers]

That issue is also discussed at #47 (comment). It seems like the conftest.py thing can be worked around fairly easily (e.g. by naming the file _conftest.py in the source tree, as in that discussion). However, the real problem is still that running pytest on the source tree won't work (see the import file mismatch: in the linked message.

Design wise I think installing certain files yes/no depending on whether the build is editable isn't optimal, and meson shouldn't know anything about the difference here.

[rgommers]

I believe this is completely addressed with the improved editable install support that is about to be released in 0.13.0, so I'll close this. In case I'm missing something @lithomas1, please comment/reopen.

[tobiasdiez]

Here is another application where it would be handy to know the type of install in meson. Cython supports to embed the source file in the docstring (https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#Cython.Compiler.Options.embed_pos_in_docstring). This is handy for local development (i.e. editable), since it easily allows you to find the declaration of a function etc. For "real" installations in distributions/from pypi, this is not useful as the cython source code is not installed anyway.

[eli-schwartz]

Meson doesn't have a way to modify the build based on this, so you'd probably need to add a project option. Meson-python could e.g. detect when that project option exists and then set its value when called from build_editable.

[eli-schwartz]

This specific case may be better suited as passing custom cython_args via config settings.

[rgommers]

We've since grown an IS_EDITABLE test utility in NumPy. On Python >=3.13 there's a reliable way to check this:

import importlib.metadata
distr = importlib.metadata.distribution('numpy')
is_editable = distr.origin.dir_info.editable

On older versions it's more hacky:

https://github.com/numpy/numpy/blob/175720eb49365b77fe7c735b883d9367a971f90f/numpy/testing/_private/utils.py#L62-L80

This should work for runtime needs though. For build-time needs (a lot more rare), adding a custom build option may be better? It is technically possible for meson-python to standardize a name, introspect meson.options and then pass a boolean flag if that name is detected, but I'm not sure if the extra complexity of that is justified.

[eli-schwartz]

Sure, adding a custom build option is what I said too. But I don't see how that helps on its own.

Users say: pip install -e .
Meson-python says: "great I'll go build that for you using the default meson options"

Now your editable install does not in fact have the thing that the custom build option was literally designed to do?

...

It is possible for users to do both -e as well as -Csetup-args=-Deditable=true but the ergonomics of the latter aren't great for something that purports to be a direct top-level feature of build backends.

[rgommers]

It is possible for users to do both -e as well as -Csetup-args=-Deditable=true but

Yeah that's what you'd need indeed, that's the tradeoff. Making meson-python more complex for all packages, or add a standard name so the packages that need to know if it's an editable build at build time can omit passing an extra option like -Csetup-args=-Deditable=true.

I think we should be open to adding this to meson-python, but it's not yet clear to me that anyone will actually use it. @tobiasdiez's case can also be handled by simply unconditionally passing the relevant Cython flag I think (if sources aren't installed for regular builds anyway it doesn't matter whether the flag is passed or not).

[eli-schwartz]

@tobiasdiez's case can also be handled by simply unconditionally passing the relevant Cython flag I think (if sources aren't installed for regular builds anyway it doesn't matter whether the flag is passed or not).

This is true but the flip side is that installing the wheel will then contain "useless" and possibly confusing explanation. If this is in the docstring itself then does that mean that when I install someone else's module and do help(), I (eschwartz) get told to go look at the details in /home/tobiasdiez/Projects/sage/.... ?

[rgommers]

Never mind, that's my brain not working. Obviously you don't want that path in rendered docs / production builds.

Okay, so we have one potential user. Let's reopen the issue and see what @dnicolodi thinks.