Attempting to address #443

I think I'd rather just have the static __version__ without any magic at all.

Done.

Should the changes to setup.py from https://github.com/fredrik-johansson/mpmath/pull/422/files be reverted too?

It makes no difference to me how setup.py is written as long as it works. I believe that commit did fix some of the metadata, so better to patch it as needed than to revert, unless it's somehow broken in other ways now.

setup.py does require setuptools now, perhaps unnecessarily. That could matter, though it isn't nearly as big of a deal as the library runtime depending on it.

I've maintained SymPy with the version duplicated in the tag and the code for years with no problems. You just remember to update the version in the code when you release, and then git tag after making the release.

On the other hand, a run dependency on setuptools creates many problems. It also forces upstream projects like SymPy to depend on setuptools by proxy, which we would like to avoid.

If you want to version based on tags, there are projects like versioneer, which I use myself in several projects, which let you do this without any additional runtime dependencies. The main advantage is getting git version version numbers that include the commit hash. The actual nonduplication of the version number isn't a huge deal. The advantage to having them separate is you don't actually tag until after the release is made (though that generally isn't a big deal as tags aren't "permanent" until you push them up).

I've maintained SymPy with the version duplicated in the tag and the code for years with no problems.

And I have seen several project, where duplicated versions were out of sync... Maybe even the mpmath in past. This only means, if you did no error yet - you will do error, eventually.

On the other hand, a run dependency on setuptools creates many problems.

For example? As I said in the issue thread - setuptools is the recommended tool for package management in the python ecosystem. Using setuptools allows simple tracking of hard and optional requirements and many users are already familiar with pip/setuptools (less installation instructions, etc).

It also forces upstream projects like SymPy to depend on setuptools by proxy, which we would like to avoid.

Why at all you should care about dependencies of the project, which you require? This may harm SymPy, if it will install own requirements, which has conflicts with other requirements of SymPy itself (pip will prevent such a situation). But I fail to see how setuptools may introduce such a conflict...

PS: SymPy is a good example of bad practice, where you fork almost everything you depend on. Should mpmath encourage this? I doubt.