semantic_version parsing fails with non semantic version constraints about poetry2conda HOT 5 CLOSED

I've also encountered this problem and would like to solve it.

I don't think that having poetry as a dependencies is a bad idea to use the version parsing code. poetry discourages installing poetry directly if it is the command you will use to manage other packages. Unless you recommend that people do poetry run poetry ... in the project dir, it should be fine.

The alternative would be to re-implement the version parsing code which shouldn't be too hard but can introduce a lot of code (probably in a secondary file).

I'm fine with either approach, do you have a preference?

from poetry2conda.

I prefer not to re-implement version parsing code because there are a lot of caveats in it. For example, the caret of versions prior to 1.0 is different than after that first stable version.

I skimmed a bit of the new poetry organization, and it seems that it would be very lightweight to use poetry-core as a dependency and use their version parsing:

https://github.com/python-poetry/core/tree/master/poetry/core/semver

from poetry2conda.

All right, I'll go with that.

from poetry2conda.

I've got it mostly working (using poetry-semver, because it's smaller), but there is still a bug in the version parsing of poetry where it will ignore the end of a version spec sometimes.

The version string that triggers it for me is '0.7.1dev1+1.*' where it ignores the '.*' part.

I've submitted a PR with a fix: python-poetry/semver#3, but it doesn't work with python 2.7 and I'm not sure how to make it work.

I've checked and poetry-core and poetry itself also have the same problem so switching is not a solution (otherwise I would have).

from poetry2conda.

OK thanks again for your contributions.
I am going to accept the PR #6 since it is certainly better than the first, previous version.

I am not too worried about something that does not work with Python 2.7. Do you still have legacy projects?

from poetry2conda.