Unmaintained?

[BrendanBall]

Is this package no longer being maintained? If so can we possibly hand it over to someone else? It's a bit crappy if an unmaintained package called network-manager sits on crates.io.

[majorz]

We have been working on a new version of the library where it is based on libnm (higher level) instead of D-Bus (lower level). Reasoning is that we would like to avoid competing with libnm, which is the native wrapper library of NetworkManager. Unfortunately progress is not fast, but we will release it as soon as we have a chance to complete that work.

[majorz]

Closed the issue by mistake.

[timbodeit]

I've spent about a day looking at libnm and the rust gir tool. Regarding my personal needs in my current project, the abstraction libnm might offer over dbus is not worth digging through the additional complexity and putting in the work required to get the gir bindings to work reliably. I don't see a functional advantage as libnm seems to be only a c wrapper around the same dbus api.
The trade-off might be different for someone who strives to create bindings for the entirety of features that the network manager has to offer, compared to someone who only needs access to a small subset of features. Until someone completes such a project, the current dbus based network-manager crate will still be the most viable option for various use-cases.

I understand that your current priorities are different from mine and don't want to argue with your decision of moving to a libnm based implementation. The question of maintenance in my opinion rather comes down to the handling of contributions.
The central question is: Are you still willing to accept contributions to a d-bus based implementation until you have completed the new major version using libnm?

I do understand reviewing pull requests takes time and is not particularly attractive, when you don't have any productive use for the changes yourself. At the same time, I agree with @BrendanBall in the sense that leaving a project sitting with open, uncommented pull requests for over a year, is not a good solution for the meantime.

Would you be willing to authorize an additional maintainer, if someone were to commit taking care of d-bus based pull requests?
What role would the network-manager crate play in a libnm based implementation? Would transferring ownership of this entire repository and releasing the new implementation under the libnm crate name be an option for you?
Is there anything that we can do to support you in getting existing pull requests merged and released without you adding an additional maintainer?
Or would you like to leave this project sleeping as is? Would you prefer other users of the current state to fork the project and maintain a separate version under a new name?

In the last case, could you please document such a decision (possibly alongside the reasoning laid out in your comment above) in the Readme, to make the current state of the project clear to new visitors of the project and to possibly prevent people from wasting time on a pull request that nobody is going to review? Would you be open to endorsing a fork publishing a differently named crate, in the meantime until network-manager ships with a new major version and the completed libnm based implementation?

[majorz]

@timbodeit Sorry for the delayed response here. The libnm based implementation is now ready. In the next days I will be adding more examples and then it will be published to crates.io.

The WIP repository is located at https://github.com/balena-io-modules/libnm-rs and it is ready to be used.

It provides full API coverage with some small exceptions that are still not implemented in the Rust glib bindings. Left are some methods that are not commonly used, but those will be added gradually as well.

Hopefully this recent development gives an answer to your questions, but if you have any other please let me know.