3.5.1 and 3.5.2 tarballs fail to build (uv-dynamic-versioning errors)

[xiota]

Describe the bug

Attempting to build from tarball fails. Errors appear to be related to building from tarball instead of git checkout. I didn't save the error messages, but can regenerate them if necessary.

To Reproduce

1. Download and extract 3.5.1 or 3.5.2 tarball
2. Try to build with: python -m build --wheel --no-isolation --skip-dependency-check

Expected behavior

Wheel should be created, as was with 3.5.

Workaround:

python -m venv venv
source ./venv/bin/activate
pip install toml-cli

toml set --toml-path pyproject.toml build-system.requires '["hatchling"]' --to-array
toml unset --toml-path pyproject.toml project.dynamic
toml unset --toml-path pyproject.toml tool.hatch.version
toml set --toml-path pyproject.toml project.version "3.5.2"
deactivate

Meta

Succeeds: https://github.com/pyinfra-dev/pyinfra/archive/refs/tags/v3.5.tar.gz

Fails: https://github.com/pyinfra-dev/pyinfra/archive/refs/tags/v3.5.1.tar.gz https://github.com/pyinfra-dev/pyinfra/archive/refs/tags/v3.5.2.tar.gz

[Fizzadar]

Looks like an unfortunate side effect of moving to uv-dynamic-version. There is a hack here which should at least get the build working: https://github.com/ninoseki/uv-dynamic-versioning/issues/64

Choices seem to be:

a) stick as-is, and tarballs/other installs require manually setting the version b) remove dynamic version and just bump it in pyproject.toml each release alongside changelog

Leaning towards b)...

[ninoseki]

Sorry to jump-in, just want to make it clear, it's not only about uv-dynamic-versioning but uv/hatchling issue.

First, pyinfra uses uv with hatchling build backend. So python -m build doesn't work since build is no longer used. A correct way to handle this is python -m hatch build (you may need to install hatch by pip install hatch).

Second, uv-dynamic-version causes a trouble because it fails to find a VCS based version in this case.

Workarounds are settings fallback-version in pyproject.toml:

[tool.uv-dynamic-versioning]
fallback-version = "0.0.0"

or using UV_DYNAMIC_VERSIONING_BYPASS env:

UV_DYNAMIC_VERSIONING_BYPASS=0.0.0 python -m hatch build

[xiota]

The build module is supposed to be a universal front end. The contents of the wheel files generated by python -m build --wheel and python -m hatch build are identical.

Setting UV_DYNAMIC_VERSIONING_BYPASS produces the same wheel as the toml edits to set the version and adjust depends.

Would be nice if tarballs just worked (option b), but I suppose may be good enough that workarounds are documented in this issue.

[ninoseki]

The build module is supposed to be a universal front end. The contents of the wheel files generated by python -m build --wheel and python -m hatch build are identical.

I understand what you mean. But it doesn't work in this wild wild west world. There are many libraries use hatchling, etc. with plugins, poetry-dynamic-versioning, hatch-vcs, and so on. and they have tarballs that don't work as you expected. (Disclaimer: I have a very opinionated opinion because I'm an author of uv-dynamic-versioning)

Finally, it depends on a maintainer's choice.