Deprecated API (sysfs::gpio)

Having inherited code form a previous developer. I am stuck trying to figure out how to handle deprecated API (sysfs::gpio) is creating an error on compiling.

In his old code he has

use sysfs_gpio::{Direction, Edge, Pin, PinValueStream};

Evidently PinValueStream is

  1. not part of that API anymore, and
  2. the whole API is deprecated in favor of another method (gpio::cdev)

The odd thing is this same code compiled without error a few weeks ago but now I get :
error[E0432]: unresolved import sysfs_gpio::PinValueStream

** |**
12 | use sysfs_gpio::{Direction, Edge, Pin, PinValueStream};
** | ^^^^^^^^^^^^^^ no PinValueStream in the root**

and

error[E0599]: no method named get_value_stream found for type sysfs_gpio::Pin in the current scope
–> src/system/mod.rs:116:32
** |**
116 | let value_events = pin.get_value_stream(handle).map_err(|e| format!("{:?}", e))?;
** | ^^^^^^^^^^^^^^^^**

error: aborting due to 2 previous errors

Now what has me scratching my head is that the ‘main’ binary (in another /src directory) will compile as if the error did not occur but then the function this API was dependent on, does not work (of course).

And yes. I know that sysfs::gpio has been ‘replaced’ by gpio::cdev but the system is locked down at L3.14.78 and will not advance until the next version of the hardware (an ARM based embedded system).

I consider myself still a noob as far as RUST is concerned and any help would be very much appreciated.

It took me several weeks to unravel cross dependencies wrt dynamic versus static executables. But this deprecation has me confused.

Small disclaimer: This is just a guess, as I never used any of the crates:

Those items are dependent on a use_tokio feature. Apparently that was at some point changed from simply being called tokio. So I’d check the Cargo.toml for that.

Apologies if this doesn’t help.

Hi phaylon,

No need to apologize. Even the smallest shred of a hint is helpful in pointing to a short term solution. .

The Cargo.toml file has references to tokio but what confuses me is this error just appeared out of nowhere. I can understand it is deprecated in favor of another API, but why does it now generate an error? where it didn’t three weeks ago. The only mod was changing ‘rlib’ to ‘dylib’ in the [lib] crate-type

[dependencies]
bytes = "0.4"
futures = "0.1"
futures-cpupool = "0.1"
lazy_static = "1.0"
mio = "0.6"
serde = "1.0"
serde_derive = "1.0"
socketcan = "1.7"
tokio-core = "0.1"
tokio-io = "0.1"
enum-common = { path = “…/enum-common” }
enum-derive = { path = “…/enum-derive” }
service = { path = “…/service” }

[lib]
crate-type = [“dylib”]

[dependencies.sysfs_gpio]
version = "0.5"
features = [“tokio”]

but I am at a loss as to

  1. how this error just appeared, and
  2. How to get around it for the near term, until I can address the deprecation.

Being that I never saw a line of RUST until late April, and I have been around computers (and languages) since the 1970s, I have been surprised at the complexity of maintaining simple items and the rather cryptic syntax of RUST.

So, having a closer look, it seems that version 0.5.4 of sysfs_gpio was released about two weeks ago, and the version before (0.5.3) still calls the feature tokio. From a quick glance, the feature name changed because they upped their tokio dependency to a newer version and the optional dependency handling changed.

Since your Cargo.toml specifies 0.5 as the dependency version, you got upgraded to the new one. The binary works because it probably has a Cargo.lock that locks the version in place unless manually upgraded. But that only works for binaries, not for trying to build the library standalone.

So, I’d say there are two options:

  • Accept the new version of sysfs_gpio and switch the features = [“tokio”] to features = ["use_tokio"]. Note that I have no idea what else changed with the new version. You’ll probably want to test if the dependency upgrade still has everything working.

  • Solution two is to change the version = "0.5" to version = "=0.5.3". This will lock the library into this exact dependency. That should have it on-par with the binary. Though it might be a good idea to examine the Cargo.lock of the binary, or inspect its build output, to see what the actual version is that it uses, as I’m only guessing it to be 0.5.3, it could be a previous one.

Edit: Some relevant links to the documentation:

1 Like

OK. reviewed the documentation , but changing the version in Cargo.toml does not change the error.

Somehow the previous developer got it to work. His code for sysfs::gpio is :
use sysfs_gpio::{Direction, Edge, Pin, PinValueStream}

Cargo.lock shows
[[package]]
name = "sysfs_gpio"
version = "0.5.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"nix 0.14.1 (registry+https://github.com/rust-lang/crates.io-index)",
"tokio 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)",
]

What confuses me is PinValueStream was part of the API but then it was deprecated and now my quandary is how to get it to compile and ignore the error.

I tried your idea, but no joy in mudville. And I am not sure how the Cargo.lock file got the newer version number injected into it (or what a valid back version is).

I haven’t yet seen somewhere that that part of the API is deprecated. It’s just behind a feature flag, and that has changed.

It’s odd that the version-fix still just gives the same error. Have you tried switching the feature name over? For completeness sake, I’ve tried a minimal example, and both

[dependencies.sysfs_gpio]
version = "0.5"
features = ["use_tokio"]

and

[dependencies.sysfs_gpio]
version = "=0.5.3"
features = ["tokio"]

allow me to build a library that has

use sysfs_gpio::PinValueStream;

in it.

Unfortunately it’s all bit hard to diagnose from afar.

Hi Robert,

I understand. Debugging from afar is not an easy task.

This one worked !!!

[dependencies.sysfs_gpio]
version = "=0.5.3"
features = [“tokio”]

Being rather new to RUST I am tripping over syntax. Both in the program(s) themselves and in some of the configuration items. Would have never thought to use the ‘=0.5.3’ to override the version.

That you could take the time to check this out (and reply) was greatly appreciated. I owe you at least a beer (or your favorite beverage).

No worries, happy to help :smiley: Yeah, the = prefix is specifically to require an exact version.