Repository navigation
Doc states that Poetry doesn't enforce #4811
Description
- I have searched the issues of this repo and believe that this is not a duplicate.
Issue
The doc on the pyproject.toml file states that:
[version] should follow semantic versioning. However it will not be enforced and you remain free to follow another specification.
I have a version looking like this: 0.4.4-11-gc91ab07. I believe it is semver valid, but the poetry build command returns the following error:
InvalidVersion
Invalid version: '0.4.4.11.gc91ab07'
at /opt/poetry/lib/poetry/_vendor/py3.7/poetry/core/version/version.py:61 in __init__
57│ def __init__(self, version): # type: (str) -> None
58│ # Validate the version and parse it into pieces
59│ match = VERSION_PATTERN.match(version)
60│ if not match:
→ 61│ raise InvalidVersion("Invalid version: '{0}'".format(version))
I've found tickets saying that Poetry does enforce PEP 440 style for versions, but it's not clear if this is still the current state of things. The doc looks wrong anyway!
I would rather have a choice since PEP 440 and Semver are not compatible and pretty much everyone else (Docker, Helm, helm) uses Semver nowadays...
Activity
dAnjou commentedon Jan 11, 2022
I think Poetry shouldn't enforce any version schema, especially not SemVer. I may have use cases where I'd like to pick a certain version name and tools shouldn't unnecessarily prevent me from doing that.
finswimmer commentedon Jan 11, 2022
I think we should rewrite the documentation here. It must be something that looks like SemVer or PEP 440 style. The python ecosystem forces to use a PEP 440 compliant version.
haard commentedon Jan 25, 2022
This breaks or complicates using e.g. CalVer, which is for a lot of projects a strictly better option than SemVer.
"The python ecosystem forces to use a PEP 440 compliant version." does not always make sense, not all projects are released to the cheeseshop - for an internal project on a steady cadence, we'd like to use YYYY.MM_nn, e.g. 2022.01_02 for the second release in January, 2022. We don't want to use 2022.01.02 because that looks like the second of January and probably ise not, and we want the releases to be string-sortable and easy to place on a timeline.
What is the reason Poetry enforces this? Notably, PEP440 specifies what "canonical public version identifiers" must adhere to, but even disregarding that rational people can disagree with PEPs, some project have non-public version identifiers and Poetry will refuse to build them (or change e.g. 1.2v003 to 1.2.post3 when building) - I'd be happy with having to give a flag to say I really want to opt out of PEP440 check or whatever, but I don't think Poetry should dictate what versions it can build.
Edit: even just pushing the check to the publish step would resolve this specific issue.
finswimmer commentedon Jan 26, 2022
Poetry is a tool for dependency management and packaging in Python. And as such it will follow PEP standards wherever possible. As you already said PEP 440 says "The canonical public version identifiers MUST comply with the following scheme".
To be able resolve dependencies you must be able to parse and "understand" the version, otherwise you cannot say if a version of a package is in the required range.
We already had a small discussion within the maintainer team a long time ago whether we drop supporting SemVer notation in
pyproject.tomlat all, because it's sometime confusing for people when the version number is converted to PEP 440 notation on install or build. We decided to leave it for now as it is.There will be a time where Poetry will move to PEP 621. At that point we have to switch to PEP 440 for the version specifier.
alsyia commentedon Jan 26, 2022
In this case, can the doc be updated? 😃
The sentence
This should follow semantic versioning. However it will not be enforced and you remain free to follow another specification.looks inaccurate since Poetry does, in fact, enforce PEP 440 (and not semver).jcmdln commentedon Mar 19, 2022
jcmdln commentedon Mar 19, 2022
jcmdln commentedon Mar 19, 2022
finswimmer commentedon Mar 19, 2022
github-actions commentedon Mar 2, 2024
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.