BLD: Fetch version from setuptools_scm at build time

[QuLogic]

PR summary

This should ensure we get the right version when tagging, etc., without having to do manual changes.

We had incorrect sdist/wheel names when building rc1 due to this: https://github.com/matplotlib/matplotlib/actions/runs/8566515999/job/23476414949#step:6:89

PR checklist

• [n/a] "closes #0000" is in the body of the PR description to link the related issue
• [n/a] new and changed code is tested
• [n/a] Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• [n/a] Documentation complies with general and docstring guidelines

[dstansby]

This seems to have broken (at least) the circleCI build:

  Traceback (most recent call last):
    File "/home/circleci/.pyenv/versions/3.9.19/lib/python3.9/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 167, in prepare_metadata_for_build_editable
      hook = backend.prepare_metadata_for_build_editable
  AttributeError: module 'mesonpy' has no attribute 'prepare_metadata_for_build_editable'

[oscargus]

Inspired by this I tried to do the same for another project and got this issue on GitHub as well. git fetch --tags seemingly solved it, so I guess that should be added to the failing CI work flow.

The thing seems to be that setuptools_scm cannot determine the version, most likely because of being cloned in a "bad" way.

  packaging.version.InvalidVersion: Invalid version: ''

(Although it wasn't required for all of my work flows for some reason... And, despite initially promising results, didn't solve it for all of my work flows, but at least for the tests...)

Edit: really not sure what the solution is, but the problem is clearly that setuptools_scm cannot figure out the correct version...

[oscargus]

Suggested change

	version: run_command(find_program('python3'), '-m', 'setuptools_scm').stdout().strip(),
	version: run_command(find_program('python3'), '-m', 'setuptools_scm', check: true).stdout().strip(),

will get rid of a warning.

[oscargus]

Sorry for spamming, but this may actually be the key thing. If setuptools_scm is not available, not having check: true will just continue running the install script. My current guess is that setuptools_scm is not installed in the failing work flows.

(I think I had an issue with tags as well, but this was the final boss in my case.)

[QuLogic]

I believe what happened here is that we used to depend on setuptools-scm for editable installs only (using some code magic to detect that), but this isn't supported in meson-python since it's almost all declarative. And initially, the Meson port just used a fixed version number without checking setuptools-scm, so it wasn't required then.

Now that this starts using setuptools-scm, it's required again, and we need to ensure we pre-install build-time dependencies for editable installs.

Was based on install failures on circle which have been resolved.

[tacaswell]

I restarted the azure failure (it was a jupyter related failure) and appveyor looks broken across all cI (gobject related).

[QuLogic]

appveyor looks broken across all cI (gobject related).

That's unfortunate that it came back; it occurred a few weeks ago, but magically fixed itself.

[anntzer]

@QuLogic This appears to have broken local editable installs (pip install --no-build-isolation -ve .) for me, essentially because find_python seems to return the homebrew-installed python (for which I have no dependencies installed) instead of the miniconda python which is actually active in my environment, per the log:

Build started at 2024-04-11T10:47:12.505883
Main binary: /Users/antony/miniforge3/envs/default/bin/python
Build Options: -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md --native-file=/Users/antony/src/extern/matplotlib/build/cp312/meson-python-native-file.ini
Python system: Darwin
The Meson build system
Version: 1.3.0
Source dir: /Users/antony/src/extern/matplotlib
Build dir: /Users/antony/src/extern/matplotlib/build/cp312
Build type: native build
Program python3 found: YES (/opt/homebrew/bin/python3)
Running command: /opt/homebrew/bin/python3 -m setuptools_scm
--- stdout ---

--- stderr ---
/opt/homebrew/opt/python@3.12/bin/python3.12: No module named setuptools_scm



../../meson.build:4:11: ERROR: Command `/opt/homebrew/bin/python3 -m setuptools_scm` failed with status 1.

Edit: this appears to have broken the ci docs build in a similar fashion, e.g. https://app.circleci.com/pipelines/github/matplotlib/matplotlib/30737/workflows/c5534721-661a-4c53-88ff-c4dcc8d1d59c/jobs/82703

[anntzer]

ping @tacaswell on the above per the call.

[tacaswell]

circle looks like it has fixed itself and I'm not seeing this problem locally (I even tried going back to the commit before this one, building, switching back to main and rebuilding).

[anntzer]

This is definitely still broken for me, and rather annoying because I need to keep running from the last commit before this PR, as later commits are totally unusable...

[tacaswell]

Checking that you did a git clean -xfd just to be safe?

[tacaswell]

I also can not reproduce this on a mac

  The Meson build system
  Version: 1.4.0
  Source dir: /Users/tcaswell/source/p/matplotlib/matplotlib
  Build dir: /Users/tcaswell/source/p/matplotlib/matplotlib/build/cp311
  Build type: native build
  Program python3 found: YES (/Users/tcaswell/miniforge3/envs/mpl-dev/bin/python3)

I tried a bunch of different versions of meson (both from pip and from conda-forge) and they all seem to work.

[anntzer]

OK, I figured it out: due to vagaries in my .profile ordering (homebrew being added to the path at a higher position than conda) my shell's python (which python) is indeed conda's python by my shell's python3 (which python3, which I never use) is homebrew's python (but fortunately(?) homebrew does not ship a python executable); and meson.build looks for python3, not python.
I guess that was brittle anyways, swapping the order of homebrew and conda in the path fixed the problem. However, I guess we should be consistent as to whether we expect to be run by the user shell's python or python3?

Thanks for looking into it.

[tacaswell]

I think this sort of brittleness is inherent in the quasi-isolation of conda / virtualenvs which rely on partially aliasing just the right things and letting through just the right other things.

When it works it is magic, when it fails it is in deeply confusing ways 🤣 .