I tried adding a Debian-specific patch to prevent this, but typically a Debian package is cleaned before applying patches, so then the version number is already gone, so this should really be fixed in the tarball.

Turns out this was not a problem after all. The changes made to __version__.py were only linebreak changes, so I think that with the fixed line endings in current master, I should be able to make this work by patching out the git version detection.

Specifically, this works for two build workflows:

• Build directly from a git checkout with dpkg-buildpackage. This applies patches before doing anything else.
• Build using gbp buildpackage in a chroot (this is my default workflow). This does indeed clean before applying patches, but it does this in an export of the git repo, which excludes a .git directory. So this does regenerate __version__.py, but without changing its contents (except for newlines previously...).

It would still break if you would directly call ./debian/rules binary or ./debian/rules clean in a git checkout without applying patches first, but I guess that's acceptable.

So, I think that the current master might actually allow a proper Debian package to be generated. It might still be good to see if this version number stuff can be a bit more elegantly fixed (e.g. not requiring a Debian patch maybe), but given the complications in #115, maybe requiring some changes in setuptools_scm, maybe release 0.5.1 first and solving this later would be better?

I'll test a tarball generated from master to confirm that there are no additional problems and report back here.

I'll test a tarball generated from master to confirm that there are no additional problems and report back here.

Just tested a tarball generated from master and that works as expected. I still have to patch out the git-version-detection, but that seems fine for now.

So, how about releasing 0.5.1 from current master, and iterating on this issue and #115 after that?

Note that it seems the auto-removal deadline in Debian has been extended (probably because the bug was reassigned by someone), so I'm not in a bug hurry, but it seems good to still just move ahead with this release and evaluate further improvements with a bit more time?