So the only downside to this approach is that for development installs, the version only updates when setup.py is re-run. On metpy, rather than have setuptools_scm write to a version file, I opted to try to use setuptools_scm to get the live version for dev installs fallback to use importlib.metadata to get the version for installed versions.

Matplotlib is different since it has compiled code and setup.py is needed to be re-run more regularly--though I bet python setup.py build_ext --inplace doesn't update the version either.

So the only downside to this approach is that for development installs, the version only updates when setup.py is re-run. On metpy, rather than have setuptools_scm write to a version file, I opted to try to use setuptools_scm to get the live version for dev installs fallback to use importlib.metadata to get the version for installed versions.

This can easily be fixed: in matplotlib/__init__.py, we can check if we are in a git repo ((Path(__file__).parent / "../../.git").exists()) and if so call setuptools_scm.get_version() instead of importing the version from _version.py. However, as described above, I have intentionally chosen against doing so: my normal Python working environment basically consists of a large number of personal projects all editably installed, and I found out that my script startup times were significantly slowed down by the large number of git describe that were run again and again every time I ran a script (also note that things are even worse on Windows, where subprocesses are even more costly to start). So nowadays I have chosen to accept the slightly out-of-syncness for my personal projects. For Matplotlib I'm fine either way.

Matplotlib is different since it has compiled code and setup.py is needed to be re-run more regularly--though I bet python setup.py build_ext --inplace doesn't update the version either.

We already hook the build_ext command to customize it, it's "probably" not too hard to customize it further to ensure it updates _version.py.

Would it be reasonable to update the version in a dev-install at runtime if setuptools_scm is available? - I assume performance-wise that's the same as versioneer currently.

Yes (that's basically the alternative I propose above).

Then I'd go with that. Feels more correct.

We can always introduce an environment variable to deactivate the lookup should the need arise to do so.

One point I forgot to ask is: do we want to add a runtime dependency on setuptools_scm (for what is a fairly rare use case)? or we can also just silently ignore the case of editable installs with setuptools_scm not present (unfortunately, I don't think "runtime dependency only for editable installs" is a thing).

setuptools_scm will become a build-time dependency anyway--which means it will be available for all useful editable installs.

No, setup_requires are not available at runtime (they're only temporarily made present in the build environment via .eggs). This can easily be checked by installing something into a temporary environment:

python -mvenv /tmp/testenv
source /tmp/testenv/bin/activate
mkdir /tmp/foo; cd /tmp/foo
echo 'from setuptools import setup; setup(name="foo", use_scm_version=True, setup_requires=["setuptools_scm>=4"])' > setup.py
git init . && git add . && git commit -m "Initial commit." && git tag v0.0
pip install -ve .
pip list

pip list shows that foo has been installed into the current environment, but not setuptools_scm (as can also be checked by trying to import it.

Discussed on call today. Decision:
Make setuptools_scm an install_requires but only for dev installs (by dynamically manipulating install_requires in setup.py depending e.g. on checking the filesystem). In __init__.py, do generate the up-to-date version from setuptools_scm, but gate that behind a module-level __getattr__ to avoid the import penalty.

Likely I won't do this in the 3.4 time frame. edit: actually that was easy :)

@anntzer I took the liberty of rebasing.

@tacaswell Is there a reason that you did not merge?

@timhoffm I think I approved, did the rebase, and then did not come back to it when CI passed. I'll rebase again and keep an eye on it this time!

Hello. I see that this is merged but astropy is still picking up git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib as 3.4.2.postN+gNNNNNN. Is this expected?