Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support PEP 621 version? #66

Closed
henryiii opened this issue Sep 6, 2023 · 7 comments · Fixed by #306
Closed

Support PEP 621 version? #66

henryiii opened this issue Sep 6, 2023 · 7 comments · Fixed by #306
Labels
feature-request New feature or request

Comments

@henryiii
Copy link

henryiii commented Sep 6, 2023

Description

I was expecting bump-my-version to be able to read

[project]
version = "1.0.0"

But it did not. If a current_version isn't specified, IMO this should be the fallback location. According to PEP 621, it is the canonical version if specified. All backends except Poetry support this now (and Poetry 2 is supposed to).

What I Did

pipx run bump-my-version
@coordt
Copy link
Member

coordt commented Sep 14, 2023

This is a great point, and I'm kicking myself for not recognizing it before.

@coordt coordt added the feature-request New feature or request label Sep 14, 2023
@ptoews
Copy link

ptoews commented Jul 29, 2024

Any update on this?

In my case I need the field at project.version so that setuptools can install my package. For that, I have to do something like this

[project]
version = "0.1.0" # Do not change this manually; Go to [tool.bumpversion]

and this

[[tool.bumpversion.files]]
filename = "pyproject.toml"
regex = true
search = "^version = \"{current_version}\""
replace = "version = \"{new_version}\""

@coordt
Copy link
Member

coordt commented Jul 30, 2024

#215 has my current answer to this.

The project.version can be dynamic, depending on your needs and build tool.

the-13th-letter added a commit to the-13th-letter/derivepassphrase that referenced this issue Feb 21, 2025
@the-13th-letter
Store the version only in pyproject.toml
dacf79e 
Establish pyproject.toml functionally as the single source of truth for
the version number, so users can rely on `importlib.metadata.version` to
query the version programmatically [1, 2].  Storing the version number
in the packaging metadata makes it directly accessible to most build
tools statically, instead of dynamically, which in theory would make
certain kinds of operations (reinstall, querying the metadata from a git
checkout) much more tractable [3].  And frankly, the only reason the
version attribute previously was dynamic was incomplete tooling support.
[4, 5]

We still retain the `__version__` attribute -- we need the version
number for the command-line interface and machinery, and querying it via
the installed packages registry is unnecessarily heavyweight -- but only
on the top-level package.  Same goes for the `__author__` attribute.

In future commits, the `__version__` attribute (and version markers in
other files such as the manpages) will be auto-generated by our build
system, commit hooks, or the like.  In general, what we still need is
a system to update all mentions of a version number across the software
package [6].

Further reading:

 1. Python Packaging Authority: [Single-sourcing the Project
    Version](https://packaging.python.org/en/latest/discussions/single-source-version/).
 2. Hynek Schlawek: [Python Packaging
    Metadata](https://hynek.me/articles/packaging-metadata/).
 3. Armin Ronacher: [Constraints are Good: Python's Metadata
    Dilemma](https://lucumr.pocoo.org/2024/11/26/python-packaging-metadata/).
 4. Barry Warsaw: [`hatch version` should be able to handle static
    version numbers](pypa/hatch#1419).
 5. Henry Schreiner: [Support PEP 621
    version?](callowayproject/bump-my-version#66)
 6. Alex Gaynor: [Scaling Software
    Development](https://alexgaynor.net/2020/feb/18/scaling-software-development/).
    "As the scale of a codebase increases, any properties of it which
    are not programmatically enforced will tend to regress."
@the-13th-letter
Copy link
Contributor

the-13th-letter commented Feb 21, 2025 •
edited
Loading

#215 has my current answer to this.

The project.version can be dynamic, depending on your needs and build tool.

It can be, yes, but it needn't necessarily be. Some people even make cases against such dynamic metadata. (Though with little success.) And it seems baffling to me to refuse support for project.version just because it sometimes is dynamically set, as if this were difficult or impossible to tell. (It's not: PEP 621 says any project.version is dynamic if and only if version appears in the project.dynamic array.)

@coordt, would you accept a PR that detects static vs. dynamic project.version, and, if it is static, uses that as a fallback value for tools.bumpversion.version, before consulting git tags?

@coordt
Copy link
Member

coordt commented Feb 22, 2025

I'll be happy to look at it. I don't want a "hack" to make it work. If you see a better way to manage retrieving the current version than is currently used, I would welcome PRs for that as well.

@the-13th-letter the-13th-letter mentioned this issue Feb 23, 2025
Merged
@the-13th-letter
Copy link
Contributor

#306 has been merged, correct? Then this issue is complete, I believe. Thanks.

@coordt
Copy link
Member

coordt commented Mar 5, 2025

Thanks to @the-13th-letter for the patch!

@coordt coordt closed this as completed Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fall back to PEP 621 project.version before consulting SCM tags the-13th-letter/bump-my-version
4 participants
@coordt @ptoews @the-13th-letter @henryiii