Looks correct. I guess we should have a regression test where we prepopulate the cmdclass.

@DimitriPapadopoulos Are you interested in adding a test? Would you like guidance?

Yes, some guidance would be nice. I don't know what the modified code is for. I just fixed the obvious to be able to update Versioneer in another project, without really understanding the purpose of the modified code.

No problem. The idea is that we're subclassing existing cmdclasses so that setup() will insert versioneer code at the right place in its sequences of build steps. If you have your own cmdclass, then we will inject our code and call super() to make sure your code gets run. When you run versioneer.get_cmdclass() with no arguments, then we just subclass the setuptools defaults.

We have some unit tests, but mostly full integration tests with example projects: https://github.com/python-versioneer/python-versioneer/tree/master/test/

I think probably the easiest way to test this is just to make sure that calling get_cmdclass() on the results of get_cmdclass() is idempotent in one of our test projects. So maybe in https://github.com/python-versioneer/python-versioneer/blob/master/test/demoapp2-setuptools/setup.py:

 commands = versioneer.get_cmdclass().copy()
+commands = versioneer.get_cmdclass(commands).copy()

I think that should fail without your fix and pass with your fix.

@DimitriPapadopoulos Went ahead and tested the above idea locally, and it does break things with the error you describe. Let's see if everything works with your fix, or if things are more complicated than I thought...

Looks like it worked. Thanks!