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

[Kent Gibson <warthog618@gmail.com>]

On Tue, Nov 22, 2022 at 10:08:31AM +0530, Viresh Kumar wrote:
> 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 :)
> 

As previously mentioned, it makes sense to me for there to be functions
that return both the binding version and the libgpiod version you are
running against.  Separately, as the two are distinct.

So keeping the wrapper around the libgpiod version method for the
latter, and another function that returns the CARGO_PKG_VERSION for the
binding crate.

Then, if the user is interested, they can report them in their help,
version, log, startup banner or whatever works for them.

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

Which is a library that reads the envvars set by Cargo at compile time,
so you could also just

const VERSION: &'static str = env!("CARGO_PKG_VERSION");

and provide a function that returns that.

Cheers,
Kent.