Make the native part more portable

[ao2]

Hi,

is the restriction to linux given by the inotify dependency?

If so, a possible approach to make the native connector more portable could be to use Gio from Glib, and in particular the GFileMonitor API https://developer.gnome.org/gio/stable/GFile.html#g-file-monitor-directory AFAIU this will use different backends depending on the system (e.g. inotify on linux) and fall back to polling if there is not a native one for the system.

An example of a native connector using Gio is the chrome-gnome-shell extension: https://github.com/GNOME/chrome-gnome-shell/tree/master/connector

I also noticed that chrome-gnome-shell installs the native part of the extension in $PREFIX/bin, any idea if this is the standard practice?

[jlebon]

is the restriction to linux given by the inotify dependency?

Mostly because I only use Linux and I only have Linux to test with. :) The inotify dependency is just an artifact of that. I'd be OK with switching from asyncio to Glib if it means cross-platform (though interestingly, this project started as an exercise to get acquainted with asyncio), but I'd rather not go through the hassle without being able to actually verify that it indeed works cross-platform. FWIW, I would definitely consider patches that do this, though I'm worried about maintenance afterwards if I can't debug/resolve non-Linux issues.

I also noticed that chrome-gnome-shell installs the native part of the extension in $PREFIX/bin, any idea if this is the standard practice?

Hmm, I find that odd. ISTM like it belongs more in $PREFIX/libexec since it's not something that would make sense in users' $PATH. You should be able to just override LIBEXEC at install time to change that though if you'd like.

[ao2]

[...] I'd be OK with switching from asyncio to Glib if it means cross-platform (though interestingly, this project started as an exercise to get acquainted with asyncio), but I'd rather not go through the hassle without being able to actually verify that it indeed works cross-platform. FWIW, I would definitely consider patches that do this, though I'm worried about maintenance afterwards if I can't debug/resolve non-Linux issues.

I too only use linux, so even if I experimented with porting the connector to Gio I wouldn't be able to easily test it on other platforms. My inquiry was mainly out of curiosity.

However it's an option to keep in mind, It'sAllText was quite popular and Textern seems to me the most promising alternative because it does not require editor-specific plugins like other extensions do.

Hmm, I find that odd. ISTM like it belongs more in $PREFIX/libexec since it's not something that would make sense in users' $PATH. You should be able to just override LIBEXEC at install time to change that though if you'd like.

Maybe they execute their native part also from the command line, for testing, not sure.

Anyways I see that $PREFIX/libexec is not very common either: in the whole Debian archive only two packages use it, more common paths seem to be $PREFIX/lib/$NAMESPACE/libexec or $PREFIX/share/$NAMESPACE/libexec.

Check out the output of apt-file search libexec/if you are on a Debian based system.

Ciao, Antonio

[jlebon]

Interesting. It's a pretty common pattern in Fedora/RHEL/CentOS at least: https://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir.

I mainly use Fedora and had assumed this was the case cross-distro, though it looks like a fundamental difference between Debian and Fedora guidelines: https://lists.debian.org/debian-devel/2005/05/msg00401.html.

Hmm, not sure. Seems like it's safer to just put them under $PREFIX/libexec/textern/ and allow folks to override if they'd like?

[ao2]

Interesting indeed, I didn't look beyond Debian.

Since there is not a standardized path for libexec binaries I agree that leaving the current one is OK, distro can always override it in case they want to package the native part.

Thanks for the followup.

[phdru]

https://pypi.python.org/pypi/watchdog revived, I'll try to use it.