I couldn't find more context behind this built-in logic that modifies the URI beyond what's written in the comment. It seems that it was introduced with the initial commit.
Despite what the comment suggests, from my own experience this logic in fact seems to make it less convenient to use the library on darwin, because of the assumptions made about how libvirt runs and where does it place the socket.
At the time of writing the default Homebrew formula for libvirt by default runs in the session mode (without elevated privileges), which ends up placing the socket(s) under ~/.cache/libvirt/ directory. Alternatively the service may be launched as root, in which case the sockets end up in /usr/local/var/run/libvirt/. Neither of these paths seem to match the one in source code.
Either way even without any configuration and service file, libvirt is capable of starting the daemon automatically upon connection to just qemu:///session (without explicit socket argument) and consumers of fog-libvirt cannot take advantage of this autostart feature.
I couldn't find more context behind this built-in logic that modifies the URI beyond what's written in the comment. It seems that it was introduced with the initial commit.
Despite what the comment suggests, from my own experience this logic in fact seems to make it less convenient to use the library on darwin, because of the assumptions made about how libvirt runs and where does it place the socket.
At the time of writing the default Homebrew formula for libvirt by default runs in the session mode (without elevated privileges), which ends up placing the socket(s) under
~/.cache/libvirt/directory. Alternatively the service may be launched as root, in which case the sockets end up in/usr/local/var/run/libvirt/. Neither of these paths seem to match the one in source code.Either way even without any configuration and service file, libvirt is capable of starting the daemon automatically upon connection to just
qemu:///session(without explicit socket argument) and consumers of fog-libvirt cannot take advantage of this autostart feature.This is also mentioned here: https://blog.wikichoon.com/2016/01/qemusystem-vs-qemusession.html
I would be open to removing that logic entirely but I thought this patch strikes a balance wrt backwards compatibility.
Let me know what you think!