search

enthought / ets

ets.py is a utility to clone and manage various Enthought Tool Suite packages
http://docs.enthought.com/ets
Other
34 stars 11 forks source link

Introduce version info as a tuple of int #44

Open kitchoi opened 4 years ago

kitchoi commented 4 years ago

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. https://github.com/enthought/pyface/pull/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: https://github.com/enthought/distributed-array-protocol/issues/16

rahulporuri commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I'd drop the serial part, though.

mdickinson commented 4 years ago

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.