Hi all, (I have now ran into this issue often enough that I thought I should bring it up on the list.)
I have recently created this issue [0] to describe this problem. I'd suggest having a read through that issue to get some background on this issue. The gist of it is that BuildStream complains at runtime (not build time) that it doesn't have any tags. Versioneer (also, its predecessor setuptools_scm) is really good at solving that problem that it does, i.e. managing versions based on scm tags. I am not disputing that. I am saying that this is not a problem we need to have. As an alternative, we could simply bake-in the version number as part of version control. This is also a tried and tested strategy for managing version numbers. Pip itself for, example, manages its version in this manner [1]. The obvious downside is that the some one/thing else is going to have to push a tag to the git repository separately after changing the version number. Although I don't think this is that adds too much to the release ceremony, but this can easily be automated if we wish. (For example if `setup.py --version` returns something greater than previous tag, an automation could create and push a new tag.) Not relying on Versioneer will mean that if someone managed to _somehow_ get all the buildstream source files untampered, they'd end up with a working copy of BuildStream. As I mention in the issue, this can happen due to multiple reasons, ranging from for performance to ignorance.. to default flags (like BuildStream's very own `track-tags: false` default). Personally, I think this collective lost productivity justifies the chore of having to tag the scm version separately. Let me know what you think! Cheers, Chandan [0]: https://gitlab.com/BuildStream/buildstream/-/issues/1383 [1]: https://github.com/pypa/pip/blob/master/src/pip/__init__.py#L7
