Build fails because of missing project.version in pyproject.toml

[iisakkirotko]

Hi!

I noticed that since a couple days ago, our CI's daily run at https://github.com/widgetti/solara is failing due to a build error for this package (see, for instance, this run). The error is:

  💥 maturin failed
    Caused by: `project.version` field is required in pyproject.toml unless it is present in the `project.dynamic` list

Looks like since the last release of maturin, setting project.version either statically or dynamically in pyproject.toml is required, as per PyO3/maturin#2391.

Could this be added to the project?

[andy-maier]

This is a new check added by maturin 1.8.0, which now requires that pyproject.toml either specifies a static version, or specifies that the version is dynamic.

I think that is a reasonable requirement, and think that the statement for dynamic versioning should be added to pyproject.toml:

[project]
. . .
dynamic = ["version"]

For completeness, see also this: PyO3/maturin#2416

[andy-maier]

Another observation: I tried to understand why the error shows up only on Python 3.8 and only when using the latest pywinpty version 2.0.14, and here is the answer:

pywinpty 2.0.14 no longer uploaded wheel archives for Python 3.8, even though it requires Python >=3.8 according to its pyproject.toml file. That causes the wheel archive to be built when installing pywinpty on Python 3.8, which then runs into the new check in maturin 1.8.0. With other Python versions and older pywinpty versions, the wheel file from Pypi was downloaded and installed, so maturin was not used when installing pywinpty.

I think it is a good idea to upload wheel archives always for all supported Python versions, to avoid such surprises.

Given this, I would expect your local build of wheel archives to also fail with maturin 1.8.0, unless the versioning is added to pyproject.toml.

[iisakkirotko]

Looks like maturin made the error less fatal (see PyO3/maturin#2417), which allows the build to pass. However, project.version should still be set somewhere, so I suppose it's best this issue remains open.

[finnagin]

It looks like this same issue breaks the build for all versions of python in the windows test workflow. This was blocking me on something else I was trying to test in a fork so I tried implementing the fix mentioned a few comments back and it seems to have worked.