Open C0rn3j opened 2 weeks ago
OK, I see. That's a design problem. We decided to have a single source of truth, and this single source is Git now. So, if you download a tarball, that's not enough. From my point of view, we have to decide between
I think we don't want to create a second commit with an updated version number in the CI for each code change commit. Think of how the history would look like.
How do other projects solve this problem? Every user of setuptools-scm
must be affected. Other projects I know actually use tarballs as archive only and always build from git.
There seems to be an env variable SETUPTOOLS_SCM_PRETEND_VERSION_FOR_${PACKAGE_NAME}
that might be used for non-git builds. But this doesn't help in finding an appropriate value. Is it maybe possible to add some file on creation of a a source tarball?
Idea: we could manually create a source zip in the CI including the version info.
One thing we could do is detect lack of .git and try parsing the parent directory in that case - i.e. sc-controller-0.4.9.5
.
Good idea. AFAIK, this directory name should be composed of the project name and release version. So even branches / tags could be handled properly.
@git-developer Integrating setuptools-scm in #30 broke this.
We could disable the Assets generating the source builds and make everyone clone from git, but:
We could simply also hardcode a "unknown version from tarball" string or otherwise hardcode some version, but that might make supporting it a nightmare, it would break the daemon vs sc-controller version mismatch detection and possibly confuse the users too.
What we could do that'd possibly be a good solution is have the CI commit the calculated git version to the repo automatically?
But I am unsure how to do it in a way which would actually be up to date and not
current version - 1
.I am blanking out on any other good solutions.