Feature request: override/pretend a version by environment variable

[gertvdijk]

I'm looking for the equivalent of SETUPTOOLS_SCM_PRETEND_VERSION environment variable as available in setuptools-scm, for versioningit.

Would be great if that's possible without the need to write a custom versioningit method. My use case is a build in Docker where I can exclude the (huge) .git/ folder from the Docker context, have no dependency on git tooling in the image and just supply the version from the host as Docker build argument.

[jwodder]

I see the following problems/complications with this idea:

• When such an environment variable is present, the querying of the VCS would be skipped, and so the only fields available to the write and onbuild steps would be {version} and {version_tuple}. While this has precedent with the fact that only those fields are guaranteed to be present when tool.versioningit.default-version is set, the difference is that the package author must deliberately choose to use default-version, whereas an environment variable can be set by anyone building or installing the package, which leads in to problem number 2....
• If this is implemented as a single VERSIONINGIT_PRETEND_VERSION envvar, then setting the envvar when building or installing a versioningit-using package will result in the envvar being recursively propagated to all build or runtime dependencies, and if any of those use versioningit, they'd get their versions overridden. setuptools_scm happens to also support a solution to this problem, per-project SETUPTOOLS_SCM_PRETEND_VERSION_FOR_${UPPERCASED_DIST_NAME} envvars, but versioningit can't easily adopt that, as it only has access to the project name when invoked through the setuptools hook and not when run via the versioningit command or the library API.

---

Side note: You may be able to address your original Dockerization problem by building a wheel (which will have the appropriate version and not contain any .git/ data) for your project outside of Docker, copying the wheel into Docker, and then running pip install ./projectname-*.whl inside Docker.

[bulletmark]

I started with setuptools-scm, then went to versioningit due to a small issue, but have now moved back to setuptools-scm due to this issue which pertains not only to Docker. Unfortunately I am finding that building an Arch Linux AUR package is awkward without an SETUPTOOLS_SCM_PRETEND_VERSION equivalent.

[sarnold]

I had the same question re OS packages from github-generated archives which seem to be the most common source used for packaging GH projects. Obviously packaging tools differ from one distro to the next, but several of them rely on the SETUPTOOLS_SCM_PRETEND_VERSION thing to facilitate packaging bare GH archives. Could you elaborate a bit more on your rationale? I would thankfully use such a feature and not use setuptools_scm for my own projects.