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

Dependency poetry-semver seems to be deprecated #40

Closed
spoorcc opened this issue Dec 23, 2022 · 2 comments
Closed

Dependency poetry-semver seems to be deprecated #40

spoorcc opened this issue Dec 23, 2022 · 2 comments

Comments

@spoorcc
Copy link

spoorcc commented Dec 23, 2022

requirements-detector requires poetry-semver which has been archived recently: https://github.com/python-poetry/semver.

Maybe the more active https://github.com/python-semver/python-semver/ could be a good alternative?

@carlio
Copy link
Member

carlio commented Feb 15, 2023

Hmm... "This is a development version. Do NOT use it in production before the final 3.0.0 is released." doesn't make we want to use this instead. I'm trying to clean up this repo right now, I'll figure something out instead. (the 2.x versions only support up to python 3.7 apparently)

@carlio
Copy link
Member

carlio commented Feb 16, 2023

I looked into this more and the problem is that python-semver only deals with parsing of an individual version spec, but cannot handle poetry's additional formatting (the ^ and ~ specifiers for example).

Although the poetry-semver repository has been archived and the code folded into the main poetry repo as far as I can tell, the 0.1.0 version on PyPI is still there and so requirements-detector can continue using it. I doubt they'd yank it since they haven't yet.

The only reason this would become an issue is if they change how the poetry requirement specification works and the old code is out of date, but I imagine they won't as they'd break millions of pyproject.toml files. And if they do, well I'll deal with that then .

So for now I'll just leave the dependecy as is, because there are no viable alternatives and I don't think the risk is big that the current dependency will stop working or go away. It's not ideal but the other solution would be to re-implement it and I started and realised it'd be a huge amount of work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants