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.

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

Add "canonical version" option to "poetry version" #9616

Closed
david-waterworth opened this issue Aug 10, 2024 · 3 comments
Closed

Add "canonical version" option to "poetry version" #9616

david-waterworth opened this issue Aug 10, 2024 · 3 comments
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged

Comments

@david-waterworth
Copy link

david-waterworth commented Aug 10, 2024

Issue Kind

Brand new capability

Description

I'm using python-symantic-release which is generating pre-release versions in the format "0.8.0-dev.2". When I run poetry version -s I get "0.8.0-dev.2" (i.e. literally the version that python-symantic-release added to pyproject.toml but when I run poetry build the version in the filenames is "canonicalized" i.e.

+ poetry build
Building my-project (0.8.0-dev.2)
  - Building sdist
  - Built my-project-0.8.0.dev2.tar.gz
  - Building wheel
  - Built my-project-0.8.0.dev2-py3-none-any.whl

I need to reference the file in my build script, so I need to be able to convert 0.8.0-dev.2 to 0.8.0.dev2 exactly as poetry does

Ideally poetry version would have a "canonical" option

Impact

This makes it easier to write custom build scripts and integrate with other tooling

Workarounds

I've written my own python script using https://pypi.org/project/packaging/

@david-waterworth david-waterworth added kind/feature Feature requests/implementations status/triage This issue needs to be triaged labels Aug 10, 2024
@dimbleby
Copy link
Contributor

I'd suggest making a pull request, either here or - probably better - at python-semantic-release.

From a poetry point of view this feels so niche that if I were you I wouldn't want to wait on someone else showing up who wanted this enough to do it - but also probably harmless enough that a pull request had a good chance of success.

However from an ecosystem point of view I'd think there is likely more value in having python-semantic-release generate canonical versions all along.

@david-waterworth
Copy link
Author

david-waterworth commented Aug 12, 2024

@dimbleby yeah I agree I do think python-semantic-release should have support for canonical versioning - I've raised it with them (as it also fails to parse canonical version tags, i..e "Couldn't parse tag v0.4.0.dev2 as as Version: '0.4.0.dev2' is not a valid Version") - it's possible I've missed a config somewhere. If not I'll see if I can convince them to change/accept a PR, if not I'll consider doing one here.

@Secrus
Copy link
Member

Secrus commented Nov 6, 2024

That should be done by python-semantic-release.

@Secrus Secrus closed this as not planned Won't fix, can't repro, duplicate, stale Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged
Projects
None yet
Development

No branches or pull requests

3 participants