Open cauebs opened 3 weeks ago
Would maintaining version identifiers outside of pyproject.toml
be considered out of scope for uv
? For instance, updating something like a __version__
in a src/package/__init__.py
?
Or, even better, support a dynamic version like hatch does with a
[project]
dynamic = ["version"]
[tool.hatch.version]
path = "src/package/__init__.py"
It's most convenient to me to have git tag
based versioning:
https://github.com/mtkennerly/poetry-dynamic-versioning
I would love to have this functionality.
Would also love to see this... I'm currently using poetry-version-plugin in versioned projects and want to switch them to uv
Also very interested in this feature. This kind of read/update version command seems very common (not only Poetry but npm, etc) and it'd make migration to uv from other tools that much more straightforward.
Would maintaining version identifiers outside of pyproject.toml be considered out of scope for uv? For instance, updating something like a version in a src/package/init.py?
@JonZeolla I've used PDM's dynamic versioning in the past (which is essentially the same as the Hatch example you provide) but have found it kind of annoying in practice. IMO it's preferable to have the version in pyproject.toml be the source of truth. That version can be exposed in the Python package using importlib.metadata.version
:
[tool.poetry]
name = "my-package"
version = "1,2,3"
# my_package/__init__.py
from importlib.metadata import version
__version__ = version("my_package")
Personally I also like the idea of basing the version on the current git tag when using together with CI/CD. In that case it would be great if there was a command to set the version in pyproject.toml to the value of the git tag.
Personally I also like the idea of basing the version on the current git tag when using together with CI/CD.
In that case it would be great if there was a command to set the version in pyproject.toml to the value of the git tag.
Covering what bump-my-version (and previously bumpversion) do would cover that (including customizing the git tag and commit message format)
An interesting addition would be to have a way to trigger a custom script to bump the CHANGELOGs like a hook to a python script.
An even better but probably too opinionated option could be to add a CHANGELOG management system (like changie) but it might be out of scope of uv?
For others who need this.
uvx --from=toml-cli toml set --toml-path=pyproject.toml project.version $VERSION
I'm using it like this in github action.
VERSION=$(uvx dunamai from any --no-metadata --style pep440)
uvx --from=toml-cli toml set --toml-path=pyproject.toml project.version $VERSION
uv build
Consider how poetry
does it: https://python-poetry.org/docs/cli#version
My workflow looks like this:
# Show current version
poetry version
# Bump version
poetry version minor
# Add a git tag with a matching version to what's in pyproject.toml
git tag "v$(poetry version -s)"
Poetry tries to be clever to avoid needing an option to specify whether you are auto-bumping or manually setting a version:
The new version should be a valid PEP 440 string or a valid bump rule:
patch
,minor
,major
,prepatch
,preminor
,premajor
,prerelease
This assumes that no-one will ever want to use one of those strings as a version, but that seems like a reasonably safe assumption.
With hatch even when you have the version
set as dynamic and red from an example __about__.py
module and you bump hatch version $(git describe --broken --tags --always --dirty)
(that what I do on build in CI/CD) it will actually change the python module. Which is kinda nice.
With hatch even when you have the
version
set as dynamic and red from an example__about__.py
module and you bumphatch version $(git describe --broken --tags --always --dirty)
(that what I do on build in CI/CD) it will actually change the python module. Which is kinda nice.
Using uvx hatch version ...
is mostly fine, but I can't use it when it's a stub only package because there is no *.py
.
:white_check_mark: Both Rye and Poetry have this, and it's quite useful both...
pyproject.toml
file serve as the single source of truth for a project's version, easily accessible (viauv
) in CI workflows, etc.:stop_sign: The latter is where my personal interests lie: I have a CI workflow that tags and deploys releases when the version is bumped, currently using Poetry for it. I don't really want to pull in an additional tool to parse the project specs, so it's currently keeping me from considering migrating to
uv
.:scroll: My proposal is replacing the current functionality of the
version
subcommand with this, sinceuv
's version can already be accessed via the-V | --version
option, and other project management currently exist as "root" subcommands.:information_source: I'm willing to give this one a go myself if maintainers greenlight the proposal.