On 21-11-22, 15:12, Bartosz Golaszewski wrote:
This is not a blocker, I will apply this series to master later and we can add modifications on top of that, but I am now questioning the need for this function here and also the value of __version__ in Python bindings.
Previously the python bindings were built with autotools as part of the whole library. In v2 python now has a proper setup.py script and I intend to publish the bindings on pypi. It can now be built separately from the rest of the libgpiod code as long as the system satisfies the dependency for libgpiod. Example: I will split the yocto recipe for libgpiod into one for the core lib + tools + C++ bindings and another for python that will go to meta-python. The latter will depend on the libgpiod package but will be built in a separate sysroot.
In that case keeping the libgpiod API version as the Python's package __version__ (which made sense before when that code was closely integrated with libgpiod core) is no longer necessary. I'm thinking about setting __version__ to v2.0.0 (because we already had python bindings with v1.x.y versioning out there) but decoupling it from libgpiod's API version.
In your rust code all the crates already have their own versions that don't follow libgpiod's API's version. I think we should drop this function. What do you think?
whatever you and Kent decide is fine with me :)
Also: is there a standardized way for crates to inspect their version? As in: println!(crate.version()) or something?
I think that would be "version!()" [1].