bump version for ipnetwork in pnet_datalink

[matteyeux]

Hey,

small PR to bump the version of ipnetwork in pnet_datalink. Since 0.30.0 I have a build error my code :

λ ~/dev/nettest(main*) » cargo run
   Compiling nettest v0.1.0 (/home/mathieu/dev/nettest)
error[E0308]: mismatched types
 --> src/main.rs:8:17
  |
7 |             match ip {
  |                   -- this expression has type `ipnetwork::IpNetwork`
8 |                 IpNetwork::V4(ipv4) => {
  |                 ^^^^^^^^^^^^^^^^^^^ expected enum `ipnetwork::IpNetwork`, found enum `IpNetwork`
  |
  = note: perhaps two different versions of crate `ipnetwork` are being used?

error[E0308]: mismatched types
  --> src/main.rs:11:17
   |
7  |             match ip {
   |                   -- this expression has type `ipnetwork::IpNetwork`
...
11 |                 IpNetwork::V6(ipv6) => {
   |                 ^^^^^^^^^^^^^^^^^^^ expected enum `ipnetwork::IpNetwork`, found enum `IpNetwork`
   |
   = note: perhaps two different versions of crate `ipnetwork` are being used?

For more information about this error, try `rustc --explain E0308`.
error: could not compile `nettest` due to 2 previous errors

Using the snippet below :

use pnet::datalink;
use pnet::ipnetwork::IpNetwork;

fn main() {
    for iface in datalink::interfaces() {
        for ip in iface.ips {
            match ip {
                IpNetwork::V4(ipv4) => {
                    println!("{:?}", ipv4.ip().to_string());
                }
                IpNetwork::V6(ipv6) => {
                    println!("{:?}", ipv6.ip().to_string());
                }
            }
        }
    }   
}

It seems like bumping ipnetwork version fixed it. I noticed it was done in the main Cargo.toml but not the one in pnet_datalink.

[sjoqvist]

I had just completed an issue describing this, and found your pull request moments before I posted it. I would also like to see this fixed.

For future reference: This seems to have been introduced in pull request #552 and be analogue to the issue #494 (which was caused by a similar automatic pull request – #483).

[matteyeux]

Despite the fact that this PR will fix this issue, I think the best way to not have this type of errors is to setup dependabot for others subprojects of libpnet

[stappersg]

On Wed, May 25, 2022 at 08:41:29AM -0700, matteyeux wrote: I think the best way to not have this type of errors is to setup dependabot for others subprojects of libpnet

What do you need to achieve that?

[sjoqvist]

What do you need to achieve that?

I have no previous experience of dependabot and I haven't tested this solution, but isn't it as easy as adding one (or more) configuration list item(s) to .github/dependabot.yml?

[matteyeux]

@stappersg If dependabot was setup to bump the version of subprojects dependencies, this PR would not be needed because dependabot could have also updated ipnetwork in pnet_datalink.

I could have been done in for both projects in #552

[mrmonday]

Thanks!