multibranch releases convert semver version to pep440 version

[intex46]

Hello, i use multibranch releases to create alpha python packages, here my pyproject.toml config:

[tool.semantic_release]
logging_use_named_masks = true
tag_format = "v{version}"
commit_parser = "angular"
commit_message = "chore(release): release v{version} [skip ci]"
remove_dist = true


[tool.semantic_release.remote]
domain = "dev.azure.com"

[tool.semantic_release.changelog]
exclude_commit_patterns = [
    "^wip :.*",  
    "^Merged PR.*", 

]

[tool.semantic_release.branches.main]
match = "main"
prerelease = false

[tool.semantic_release.branches.develop]
match = "develop"
prerelease = true
prerelease_token="rc"

[tool.semantic_release.branches.feature]
match = "^feature/.*$"
prerelease = true
prerelease_token = "alpha"

[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"

dynamic = ["version"]
[tool.pdm.version]
source = "scm"

When i'm on a feature branch i use : semantic-release -vv version --push --no-vcs-release --no-changelog --build-metadata $(git branch --show-current) to generate my feature alpha version in order to avoid conflict with other developer who start from the same version as i , however when i push the generated wheel to artifact it convert v0.1.2-alpha1+abcd to 0.1.2.a1 , so another developer who create his branch starting from the same version v0.1.1 would have the same python package version as i and can't deploy his package to artifact since the version already exists

Is there any solution to avoid this conflict , i tried to insert the version package in the pyproject.toml file using version params but the generated version does not respect pep440 format (0.1.2.a1+abcd), so the current version will point at it which is no good for production purpose

the idea is when building the python package it will convert v0.1.2-alpha1+abcd to 0.1.2.a1.devabcd or something like this

[codejedi365]

@intex46, thank you for posting your question and rationale. I have been doing some research on the request and should have an answer for you shortly.

[codejedi365]

@intex46, first thing to note is that both the wheel builder and PSR are adhering to PEP440 format.

The version scheme you describe falls under the category of Local Version Identifiers. Local identifiers allow for build metadata to be appended to the version via a +. This is what PSR is doing when it stamps the version into pyproject.toml. Given the intent of build metadata, this is the correct behavior of PSR.

Since the build metadata is not allowed in Public Version Identifiers, the wheel build drops it upon build. This is also correct behavior.

To still accomplish your workflow, I would recommend modifying the build command that you supply PSR to call an internal script or sed command that will convert the + to a . in the version number field of pyproject.toml and then call your build command. This script would enable PSR to stamp the version in and then call your script as the build step.

[github-actions]

This issue has not received a response in 14 days. If no response is received in 7 days, it will be closed. We look forward to hearing from you.

[github-actions]

This issue was closed because no response was received.