dynamic = ["version"] in new pyproject.toml build

[nschloe]

I'm testing the brand-new pyproject.toml build backend.

[build-system]
requires = [
  "setuptools @ git+https://github.com/pypa/setuptools",
]
build-backend = "setuptools.build_meta"

When using

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

the version is always set to 0.0.0, so I guess setuptools doesn't pick it up from the packages __version__. Fair enough, I've never told it so. How can I though?

(So far, I've always used flit which does it automatically.)

[abravalheri]

Hi @nschloe thank you very much for trying it out.

To get the version from an attribute you can use:

[tool.setuptools.dynamic]
version = {attr = "mymodule.__version__"}

[abravalheri]

Sorry, that was my bad, my example was wrong. The correct form is mymodule.__version__.

(: vs .)

[nschloe]

Yup, that works. Thanks! I'll keep testing.

[abravalheri]

Thank you for testing!

[CDWimmer]

Doing this makes build try to import mymodule to fetch __version__, but due to it making its own venv temporarily in the process it doesn't have any of the extra modules in it, e.g. requests, so it fails in my case. How should this be tackled?

edit: capitalised "version" in one place but not the other... issue exists between keyboard and chair

[zahlman]

@CDWimmer The details depend on your overall file structure, but for example if you have a single top-level package mypackage and the needed __version__ is in mypackage.mymodule, you must ensure that import mypackage.mymodule (which will require import mypackage first) does not immediately, at import time cause import requests. For example, if Requests functionality is only needed in mypackage.othermodule, then make sure the import occurs there and not in __init__.py. In some difficult cases you might have to move import requests inside a function.

The relevant documentation is here. In particular, note the commentary:

Note however that importing the module is error prone since your package is not installed yet.

A far better solution is to avoid the problem entirely, by not having a __version__ attribute in the first place. Instead of trying to make your build process extract the version from your code at build time, have your code extract the version from project metadata (which was left behind by the install process, which in turn came from what you built) at runtime. Hard-code a project version in pyproject.toml instead of writing a __version__ attribute in the code; then use importlib.metadata.version to get the version number.

For example, in an environment where NumPy is installed, I can do

>>> import importlib.metadata
>>> importlib.metadata.version('numpy')
'2.0.0'

Similarly, you can modify your own code to get its own version number, assuming itself to be installed. (For development purposes, you may want to use an editable install, or else add some sort of fallback to this logic.)

Using importlib.metadata this way is the modern recommendation, as mentioned for example in the rejection of PEP 396. Unfortunately, awareness of this technique appears to be low.