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

Normalization of equivalent versions #121

Closed
di opened this Issue Feb 12, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@di
Copy link
Member

di commented Feb 12, 2018

It'd be nice if there was an easy way to get a "normalized" version, e.g.:

>>> from packaging.version import parse
>>> parse('4.1') == parse('4.1.0')
True
>>> parse('4.1').normalized_version
'4.1.0'
@di

This comment has been minimized.

Copy link
Member

di commented Feb 14, 2018

This is a little complicated by the fact that there can be any number of components in the release segment. Maybe this makes more sense?

>>> parse('4.1').normalize(3)
'4.1.0'
>>> parse('4.1').normalize(5)
'4.1.0.0.0'

I'm not sure I like it.

@di di closed this Feb 15, 2018

@dstufft

This comment has been minimized.

Copy link
Member

dstufft commented Feb 16, 2018

Did you mean to close this?

FWIW we have a packaging.utils.canonicalize_name function, so I could see this just being a function like that, which just did something like:

import re
from ..version import parse as parse_version

def canonicalize_version(version):
    # Get the string into it's "Normal" form, but this can still include additional 0s
    version = str(parse_version(version))
    return re.sub(r"^((?:0\.)+)", "", version[::-1])[::-1]

I'd have to go over PEP 440 to be sure, but that should turn any PEP 440 compatible version into a unique string. It obviously wouldn't retain the number of zero's that the package originally had, but if it's not being displayed to users that shouldn't really matter.

@di

This comment has been minimized.

Copy link
Member

di commented Feb 16, 2018

Ah. I got stuck in the rut of thinking only about adding .0s, not removing them. That makes sense.

I'll work on adding this.

@di di reopened this Feb 16, 2018

@dstufft

This comment has been minimized.

Copy link
Member

dstufft commented Feb 16, 2018

@di I realize my code doesn't really work, since you have to do like 1.0.0.dev0 and stuff to, so it probably needs to understand versions more than my snippet above does. Originally this was how the Version class worked, but I ended up altering it to keep the number of zero's.

The basic idea should still work though, it just might need to either live on the version object so it can get access to the internals to reconstruct it, or you might need to solve #34 so that the canonicalize_version() function can access the parts of a version to munge with the release segment before reconstructing it.

@di

This comment has been minimized.

Copy link
Member

di commented Feb 26, 2018

@dstufft Thanks. I made #125 to address this issue and #34, I'd appreciate your review/merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment