Able to set version using environment variable

[jonringer]

For package maintainers, we often receive the sdist, which is devoid of any vcs information, so we need another way to communicate the version number of the package to the build toolchain. For setuptools-scm, this is SETUPTOOLS_SCM_PRETEND_VERSION, however, I'm not aware of an analogous feature for this package.

To be clear, this use case is when the version is already determined, and we are just following upstream has distributed.

[mtkennerly]

In the sdist generated by poetry build, the plugin injects the correct version into the applicable files (e.g., setup.py and PKG-INFO) and reconfigures the distributed pyproject.toml to disable the plugin. That way, consumers of the sdist shouldn't have to worry about the plugin anymore. Is there some issue with that in your use case?

If the sdist still required the plugin for some reason and there were something like an environment variable as a workaround, I'm curious if you'd have a problem when you're building project A and it depends on project B that also uses poetry-dynamic-versioning. Would they end up with the same version? Do you always get the dependencies from wheels, even if that means building them from the sdist separately and one-by-one first?

[jonringer]

sorry, I forgot to mention the need for using source code as well.

As many maintainers don't export tests in their sdist; but tests are invaluable when you need to tweak dependency ranges to make a coherent package set.

[ms-lolo]

Hey just wanted to mention that this is blocking me right now. We sometimes install a package as a local-editable package into docker images. But these docker images do not get the full git repo. I need a way to set the version through an environment variable and effectively disable this plugin for the one poetry install call. In my case, if I have multiple local dependencies being installed that all use this plugin, I want them all to share the same version from this environment variable. We did this in the past using SETUPTOOLS_SCM_PRETEND_VERSION when we were using pipenv.

Cheers!

[jonringer]

In the sdist generated by poetry build, the plugin injects the correct version into the applicable files (e.g., setup.py and PKG-INFO) and reconfigures the distributed pyproject.toml to disable the plugin. That way, consumers of the sdist shouldn't have to worry about the plugin anymore. Is there some issue with that in your use case?

Sdists are often neglected. Example: https://github.com/NixOS/nixpkgs/pull/145528/files#r747757644

I'm curious if you'd have a problem when you're building project A and it depends on project B that also uses poetry-dynamic-versioning

No, each dependency is built in their own sandbox.

? Do you always get the dependencies from wheels, even if that means building them from the sdist separately and one-by-one first?

We almost never use wheels, because nix doesn't assume FHS, so we generally end up needing to groom and patch things before installation. Hard to apply patches after a wheel is created, or the package is installed.

Current practice that I've been doing is this: https://github.com/NixOS/nixpkgs/blob/83a144c2014f67366357da9b32cc0d5a1554f448/pkgs/tools/misc/copier/default.nix#L47-L53. Which is letting the version be defaulted to 0.0.0, then patching it myself.
This is annoying though. Because now I have to be aware of the internal structure of the package to know where and what to change. It would be nice if there was an abstraction to communicate this.

[mtkennerly]

Alright, that makes sense. Thanks for explaining further. I'm open to adding this.

[mtkennerly]

This is now implemented. I'm planning to get a release out within the next few days.

[jonringer]

@mtkennerly thanks a lot. Distro maintainers everywhere will thank you :)