@asmeurer, will you object this change, given the previous history (i.e. #443, #580)?
Keep in mind, that now we don't support py2 and setuptools_scm don't add additional dependencies (it's only in the build-system requirements, just like the versioner).

This doesn't appear to do the right thing if I import the local copy of mpmath. It grabs the version from the installed version rather than the version that is actually imported.

Basically, this seems to be assuming that some metadata is in sync with the source, whereas with the version being listed directly like this it's impossible for this issue to occur.

This doesn't appear to do the right thing if I import the local copy of mpmath.

Does it make sense to support this kind of workflow? (I guess, the versioneer has same problem.)

This type of workflow could be used for development. But the mpmath has a lot of optional requirements, which are actually required for developers... E.g. pytest or sphinx. In the current docs we suggest do pip install in this case as well. I think it's better: you can create a dedicated virtual environment(s) for the mpmath development, instead of doing system-wide (or per-user) installation of all that stuff.

whereas with the version being listed directly like this

The drawback is some maintenance burden for updating the version... While with the setuptools_scm we could just push a tag. Also, this versioning policy could slightly simplify bug reporting: you can show the mpmath.__version__ and it will be clear which git version you are using.