A better(?) approach may be the one at https://stackoverflow.com/a/66869528/378080 (in combination with still checking if '.git' exists): add a .editable-install-marker empty file in lib/matplotlib/, which will not be present in normal installs (as it isn't listed in package_data), but will be present in editable installs.

Or, now that I think of it, a .this-is-a-matplotlib-repo empty file in the source root dir, and then just check for (Path(matplotlib.__file__).parent.parent.parent / ".this-is-a-matplotlib-repo").exists()...

Thanks, a dedicated file .matplotlib-repo is the most clear signal.

This is prob fine but is there no other way to get our dev version info than setuptools?

This is prob fine but is there no other way to get our dev version info than setuptools?

Um, yes you only have to call git describe with the right parameters and parse the result. The problem is that the result can vary on the state of your repo and you have to translate to a standardized format of the convention you want to use. That's quite fiddly and why setuptools_scm exists. I don't think we want to get into the business of managing that logic ourselves. We use setuptools_scm only as a dev-dependency, and for devs, it's ok that they install this as well.

Should you add this file as export-ignore in .gitattributes? That will leave it out of any /archive/* tarballs, which we may want?

Maybe. I have not used archives. From what I've understood this is only relevant for git archive. I assume source distributions do not use this? So the only case would be people doing git archive themeselves. Here I have no clear view what they are trying to achieve. If they are archiving a source checkout only to bring it back later, they'd need the file to be included. If they archive to share and distribute, the file should not be included.

For example, Fedora builds from https://github.com/matplotlib/matplotlib/archive/v%{Version}/matplotlib-%{Version}.tar.gz, a tarball which GitHub creates using git archive. I think we do install setuptools-scm in the end though. And then tests are run on an installed copy, so as this is relative to the install, maybe it's fine to keep?

TL;DR The PR is good as is. This is only the explanation why.

Thinking about it, we should not exclude .matplotlib-repo from archive. We only use setuptools_scm if both .matplotlib-repo and .git are present. So the existence/missing of .git already handles that under normal circumstances - and in principle I could see both usages for an archive. .matplotllib-repo is only needed as a second level guard. It's only for the case that a not repo version is installed to a location that happens to be a git repo.

I am happy with the PR as it is (and would not bother with removing .matplotlib-repo from archives, as that's one less config item and leaving it in seems harmless), but would rather let @QuLogic do the second approval as he's the most likely to be impacted.