Cleanup

[EdJoPaTo]

Listed changes from the commits:

• Cargo.toml dependencies:
  • sorted alphabetically
  • use shorter version identifier with same meaning
• remove unused test variables
• add ; at last statement
• cargo fmt
• same mqttoptions variable name in all examples
• minor things found in Improve MqttOptions creation #391

This should also simplify the diff of #391 (this will create merge conflicts in #391 first)

[EdJoPaTo]

Anything blocking this? (Having not that much time to review is also understandable and totally valid)

[tekjar]

This mostly looks good to me. I prefer to freeze versions in libraries as well, atleast critical crates like tokio because I notices some upgrades causing perf bottlenecks in the past

[EdJoPaTo]

I prefer to freeze versions in libraries as well, atleast critical crates like tokio because I notices some upgrades causing perf bottlenecks in the past

The version identifiers which changed in Cargo.toml have exactly the same meaning before and after the change. Both 1.2 and 1 will install version 1.33.7 (when without the lock file). This is counterintuitive for me so I like the shorter version more.
The lock file is still in place and unchanged.

A different idea might be to replace the version requirements with a different strategy like tilde requirements and remove the lock file then.

Should I revert that change in version requirements in order discuss it differently from this PR?

[tekjar]

@EdJoPaTo Oh yeah. Probably just use =1.33.7 for tokio? I'm only worried about the movement of tokio's version

[EdJoPaTo]

Remove the lock file then too when the tokio version is pinned?

[tekjar]

I think that lock file is related to some binary in this workspace. I think it's all cool w.r.t this library. I'll merge this tomorrow in our opensource syncup

[adamscybot]

So the above caused some problems for me. I have another library which uses tokio transitively (dep of a dep) and since it requires 1.19, and rumqttc is now strict about using 1.17.0 -- I cant use the library. Previously, it was just at 1 which means it would work with other versions of tokio that may be required by other libs.

I suspect I'm probably not alone since tokio is very popular so in a complex app with lots of dependencies there's a very high chance usage of this library is now precluded with such a strict req.

[EdJoPaTo]

Thanks @adamscybot for bringing it up!
I think this is its own topic that might be bigger than this PR. I created an issue for discussing it in its own place.