Restore possibility to run without mainloop

[AndersBlomdell]

Addresses #84 and #66

[xvitaly]

@seveas Can you review and merge this patch?

[Hadatko]

We had to use version mentioned here: #84 (comment) as this patch is not applied.

[xvitaly]

We had to use version mentioned here: #84 (comment) as this patch is not applied.

Version 2.1 has some major compatibility issues with the modern Network Manager.

[maggie44]

Surprised this works. Thought follow_name_owner_changes was a simple boolean that just switches us back and forth between issues: https://dbus.freedesktop.org/doc/dbus-python/dbus.bus.html

Seems the issue occurred in the latest 2.2 but not in 2.1 (#84).

Only thing that changed related to this in 2.2 was the boolean changed from its default False to True (2.1...2.2).

What is follow_name_owner_changes=dbus.get_default_main_loop() != None adding? It will resolve False without dbus mainloop being set, which will restore this error (#66), or True when it is set, which seems to result in this (#87)?

[maggie44]

Here is another potential way to go about it: #90

Personally either pull request would fix the issue for me so no preference, just felt there may be some strengths to a configurable option.

Hoping one of them can be merged soon to get python-networkmanager working again. At the moment I'm stuck between the older less compatible 2.1 version or the connection dropping every 24 hours #87.

[Hadatko]

We had to use version mentioned here: #84 (comment) as this patch is not applied.

Version 2.1 has some major compatibility issues with the modern Network Manager.

Could be but for our case it is working well

[maggie44]

We had to use version mentioned here: #84 (comment) as this patch is not applied.

Version 2.1 has some major compatibility issues with the modern Network Manager.

What sort of compatibility issues? Isn't it just adding in some new types of device? c4a5913. If not using those new device types, is there any differences?

[xvitaly]

What sort of compatibility issues? Isn't it just adding in some new types of device?

Yes.

If not using those new device types, is there any differences?

It will instantly crash. See #68 and #76.

[maggie44]

What sort of compatibility issues? Isn't it just adding in some new types of device?

Yes.

If not using those new device types, is there any differences?

It will instantly crash. See #68 and #76.

Eek, ok so even if you’re not using those new devices, if they exist on your hardware then you can’t fetch and use other devices. Does make downgrading back to 2.1 risky.

[maggie44]

A cheeky bump here in the new year, hoping we can merge this. ☺️

[bernhardkaindl]

Works here, please merge!

[maggie44]

Following up in (another 😆) new year, would be great to see this one merged @seveas.

[xvitaly]

The project is dead. Someone need to fork it.

[seveas]

It's been on life support for a while. I've been trying to find someone with the right skills and willingness to take over, but with no success so far.

[bernhardkaindl]

@seveas Well, you should state it in the project's README.md, otherwise nobody will ever know and assume it was just deserted.

You could at least merge it, one year of having an independent confirmation that this PR does indeed work would be about time.

Also, it would be good to add the info that it's dead and forking is appreciated and in the README, you could, also add a list of better alternatives such as:
https://github.com/python-sdbus/python-sdbus-networkmanager

In the new 2.0rc1, it has new helper classes for easy reading of NetworkManager connection profile settings, with a nice interface to update them as well. It's used in production too.

Nobody would stop you to invite people like @Maggie0002 as project developers to your project, he already demonstrated that he is a very capable developer, better than no action for years.

[seveas]

Happy to hear there are alternatives these days, I'll just archive this repo then.

[seveas]

Closing all PR's and issues prior to archiving this repository.