Re: [libgpiod][PATCH V10 2/6] bindings: rust: Add libgpiod crate

[Viresh Kumar <viresh.kumar@xxxxxxxxxx>]

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].

-- 
viresh

[1] https://crates.io/crates/version