Backwards compatibility of get_time() -OR- implementation of the __version__ attribute

[rtrueb]

I'm using get_time(absolute_time=True, time_reference='network') in flocklab-tools which works fine with python support v1.1.6. However, in the new version (v2.0.0), the signature of the get_time function changed and is no longer backwards compatible (providing the absolute_time triggers an error). As a workaround, one could simply try to call both versions of the get_time() function. However, I think one of the proposals below would lead to a cleaner solution:

• Making the get_time function backwards compatible by accepting but ignoring the absolute_time argument.
• Keeping the new interface unchanged and implementing the __version__ attribute such that the calling software is able to determine which signature of the get_time function should be used.

[lsigrist]

Thanks a lot for your input. The behavior you are referring to is one of the documented breaking API changes of version 2.0.0. Make sure to study the CHANGELOG to familiarize yourself with all breaking API changes. See also the documentation of the new API.

Regarding the two requests you're bringing up relating to this:

• I don't understand your first comment: breaking API changes are the reason for a major version bump, see also definition of semantic versioning that we use for the RocketLogger project.
• The PEP 396 on introducing a __version__ attribute was rejected. Therefore I do not see any reason to introduce this.

In general, I highly recommend not to write any code that needs to query the package version of a dependency: rather specify the dependency on a specific package version (or version range) in your package's setup.py. This guarantees a compatible environment already at installation time of your package.

[rtrueb]

Thank you for your detailed answer. I agree with your comments and I think it makes sense to stick to one version and specify the corresponding version number in the requirements of the package.

[lsigrist]

The RocketLogger Python package actually also suffers from not specifying the exact supported version of its dependencies, see #48.