Dynamic versioning

[henryiii]

No description provided.

[bennyrowland]

@henryiii I am interested in this feature and would be happy to be involved with implementing it, but I guess that there are some design decisions to take first. For example, setuptools provides a finalize_distribution_options() entry point that allows any provider to modify the distribution metadata to inject any dynamic values (as done in setuptools_scm, for example). hatch, meanwhile, has a dedicated version plugin interface which provides a class which can both provide the version and also accept a new version, because hatch itself provides an interface for incrementing versions.

I guess that as a backend only option, scikit-build-core doesn't want anything as complicated as hatch, so I would be inclined to go more down the setuptools route. We could implement an entrypoint like scikit_build_core.get_dynamic_metadata which should be a function which provides a dict of metadata keys and values - any keys which are in the main "dynamic" list will be updated in the main metadata dict before sending it to pyproject_metadata. Alternatively we could have an entrypoint like scikit_build_core.get_version which could just return the version string and only call that if version is in the dynamic list. That is simpler, but less generic than the first option.

Let me know if any of this sounds sensible, and I will get to work on an implementation.

[henryiii]

I've got an initial implementation in 4fa6150, actually. It would be pretty easy to add (as done in that commit) if we simply require a single method using setuptools_scm. There are some other tools (like dunamai), so I paused that work to see if there was a more general way to add it that would allow other backends in the future. I also would like to support hatch's method of pulling a version from a file via regex.

We'd want some configuration options (I'd really have liked it if setuptools_scm would let me just tell it to read its normal configuration from tools.setuptools_scm!). If we did the get_dynamic_metadata option above, I guess that would be implemented by the plugin.

I'd also like to support https://pypi.org/project/hatch-fancy-pypi-readme/.

[bennyrowland]

Interesting, I hadn't seen that hatch plugin before, but that is implemented using a different hatch hook which is essentially identical to my get_dynamic_metadata() proposal above: https://hatch.pypa.io/latest/plugins/metadata-hook/reference/. In principle it seems like it can update any core metadata, but I don't know whether version is special cased so it doesn't work that way.

The only difference is that rather than a single function, hatch defines an interface class that plugins override, that class then has hatch provided methods to allow the project root and pyproject config to be passed in (so config comes from [tool.hatch.metadata.hooks.your-plugin] rather than [tool.your-plugin]).

To support hatch-fancy-pypi-readme unmodified would require collecting the hatch entry point, and matching the hook class hatch passes into the plugin. Not impossible but not super pretty either. I see that you have plans to make scikit-build-core available as a hatchling plugin, presumably that would be the best way to work with other hatch plugins? So in that case maybe the best thing to do is something very simple in the scikit-build-core backend. It would then be pretty simple to hook up setuptools_scm or hatch-fancy-pypi-readme with a couple of lines of extra code.

To be honest, I am surprised there isn't some kind of PEP standard to define an entry point system for dynamic core metadata, having defined the dynamic field, it seems like an obvious next step to define how the dynamic fields get filled in.

[henryiii]

Closed by #197.