ENH: allow to specify editable-verbose in pyproject.toml

[dnicolodi]

Build config settings passed via the build front-end take precedence over the value configured via the tool.meson-python.editable-verbose setting in pyproject.toml.

For this to work, the editable-verbose config setting is extended to take an optional boolean argument: "true" or "1" are true values, "false" or "0" are false, anything else is invalid. For backward compatibility, the empty string (no argument passed to the config setting) is treated as true.

Addresses a part of gh-820

[dnicolodi]

@rgommers What do you think of this approach?

[dnicolodi]

@rgommers gentle ping

[rgommers]

Thanks @dnicolodi, and apologies for the delay - I've been pretty swamped (now on a short holiday, so trying to catch up here).

Adding a pyproject.toml setting seems like a reasonable and clean approach. I'm not sure about is explicitly accepting 1/0 (which are untested) but not yes/no/on/off. I did a quick search on GitHub and could only found true being used; in gh-820 there's one usage of yes in a question. Either being more strict or more loose might be appropriate here?

Technically this could break someone who uses now yes or some random string, however that doesn't seem worth worrying about.

This section should probably be expanded a little: https://mesonbuild.com/meson-python/how-to-guides/editable-installs.html#verbose-mode

The docs should probably have a warning about the "install scripts" problem you explain at #820 (comment).

Question: did you consider what we discussed there, buffering to a file and only displaying on a build failure? That would probably be cleaner and wouldn't have to come with a disclaimer, but perhaps more complex to reliably implement?

[rgommers]

Thinking about that some more, an only-on-error mode is orthogonal to this, and could be added either later or instead of this. And that could be a change in default behavior, it wouldn't need an explicit setting I'd think, you always want to show the output if there's a build error.

The change to this line:

meson-python/mesonpy/_editable.py

Line 346 in e5ba90f

subprocess.run(self._build_cmd, cwd=self._build_path, env=env, stdout=subprocess.DEVNULL, check=True)

would have to be something like this (replace DEVNULL with PIPE):

proc=subprocess.run(self._build_cmd, ..., stdout=subprocess.PIPE)
ifproc.returncode!=0:
sys.stderr.buffer.write(proc.stdout)
raiseImportError(...)

[rgommers]

Ah, I rediscovered gh-750, which deals with the only-on-error case, so we should revisit that, and not reinvent that wheel here. Let's focus on the pyproject.toml settings only here.

[dnicolodi]

I'm not sure about is explicitly accepting 1/0 (which are untested) but not yes/no/on/off. I did a quick search on GitHub and could only found true being used; in gh-820 there's one usage of yes in a question. Either being more strict or more loose might be appropriate here?

Maybe accepting only true and false is more appropriate.

[rgommers]

Maybe accepting only true and false is more appropriate.

Sounds good to me.

[dnicolodi]

Updated with the discussed changes.

[rgommers]

LGTM, approving. pre-commit is still unhappy with some trailing whitespace.

[dnicolodi]

pre-commit is still unhappy with some trailing whitespace.

Fixed