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

Introduce version info as a tuple of int #44

Open
kitchoi opened this issue Aug 5, 2020 · 5 comments
Open

Introduce version info as a tuple of int #44

kitchoi opened this issue Aug 5, 2020 · 5 comments

Comments

@kitchoi
Copy link
Contributor

kitchoi commented Aug 5, 2020

ETS packages have __version__ as a string, e.g. "4.5.0". That is fine and is an expected format.

But sometimes we want to use the version information for things like skipping a test for a specific version range (e.g. enthought/pyface#656), then we have to resort to parsing the version string. It is not hard to do, but it would have been easier if a version_info or __version_info__ as a tuple of int is provided by the package already along with __version__.

e.g.

__version__ = "6.1.0"
__version_info__ = (6, 1, 0)

A similar topic was discussed a long time ago: enthought/distributed-array-protocol#16

@rahulporuri
Copy link
Contributor

sounds like https://docs.python.org/3/library/sys.html#sys.version and https://docs.python.org/3/library/sys.html#sys.version_info. Additionally, __version_info__ can be a named tuple (major, minor, micro) instead of needing to index into the tuple to get information.

@rahulporuri
Copy link
Contributor

Note that sys.version_info is a tuple of length 5 - where the last two elements represent releaselevel and serial. I'm not sure what serial refers to and I don't see much use for releaselevel at the moment.

@mdickinson
Copy link
Member

We have had release-candidate releases of Traits - the releaselevel would be useful for that.

We'd also ideally want the dev stuff to go into the version_info somewhere, for development releases.

Having said that, version comparison becomes very messy if you want to include the releaselevel component, so we probably just stick to using the first 3 entries for version comparison. If we really need to do version comparison right reliably, covering all the various edge cases, the right way is to let pkg_resources or packaging handle it rather than try to do it ourselves.

@mdickinson
Copy link
Member

I'd drop the serial part, though.

@mdickinson
Copy link
Member

The other part of this is that where possible we should do direct tests for the thing we care about rather than using version numbers as a proxy. For example, prefer a try / except ImportError around a from traitsui.api import ThingThatMightNotBeThere, rather than a version check.

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

3 participants