Repository: pwr-Solaar/Solaar

Issue:
Distribution of 42-logitech-unify-permissions.rules
I see `/usr/share/solaar/udev-rules.d/42-logitech-unify-permissions.rules` is installed by the setuptools packaging by default but it has to be installed/copied by user to e.g. `/usr/lib/udev/rules.d/42-logitech-unify-permissions.rules` for it to actually be useful and providing access to the hardware as non-root user.

Could this be installed in the expected (useful) location by default or is there some reason/limitation it's not?


Discussion:
Probably has to do with PyPI distribution where this of course is not possible whereas I'm working with Linux distro packaging of it, closing this.
wouldn't changing the path in https://github.com/pwr-Solaar/Solaar/blob/5d6d675b4a7ab981ad172a66fb7a0d960180fa0c/setup.py#L42 fix it?
The issue is not PyPI per se, but the ability to manually install Solaar (minus the udev rule) using pip without needing root privileges.    Running pip as root is considered to be very dangerous.
Hm, is there anything that could be done about it? This indeed also happens to work on my end:
```diff
--- a/setup.py
+++ b/setup.py
@@ -39,7 +39,7 @@ def _data_files():
         yield _dirname(mo), [mo]
 
     yield 'share/applications', ['share/applications/solaar.desktop']
-    yield 'share/solaar/udev-rules.d', ['rules.d/42-logitech-unify-permissions.rules']
+    yield 'lib/udev/rules.d', ['rules.d/42-logitech-unify-permissions.rules']
     yield 'share/metainfo', ['share/solaar/io.github.pwr_solaar.solaar.metainfo.xml']
 
     del _dirname
```
Where I noticed this originally and added a move workaround for the file: https://github.com/chimera-linux/cports/pull/614
The pip (and PyPI) installation of Solaar does not change system files by design, so if the Solaar udev rule needs to be installed it has to be done manually.
And I take it there is no distinction possible between pip/PyPI and distro packaging in setuptools? In that case this can be closed
> The pip (and PyPI) installation of Solaar does not change system files by design  

are you saying that installing to `/usr/share/solaar/udev-rules.d` is permitted, but installing to `/usr/lib/udev/rules.d` is forbidden by pip?
Without using sudo or some other root escalation pip can't install in system directories, which should include /usr/share.  In any case udev won't find rules in /usr/share/solaar.
> Without using sudo or some other root escalation pip can't install in system directories, which should include /usr/share.  

well, that's where the existing code puts it for a bare setuptools install..

and when using pip without root, it defaults to a user installation (which isn't affected by the above diff; it installs it to somewhere in the user site-packages, so it changes from e.g. `.local/share/solaar/udev-rules.d` to `.local/lib/udev-rules.d`). so applying it doesn't break either case, but just puts the rule in the correct place when using pip as root, or when doing a setuptools packaging build.
(something that's easy to miss is that the proposal is not to always install it to /usr but to just change the path that goes after the --prefix)
Hmm.   Changing where the udev rule goes is possible, as long as it is a relative path.   Submitting a PR is probably the best way to go.
Just for info on immutable OSes like Fedora Silverblue `/usr/lib/udev/rules.d` is readonly.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -39,7 +39,7 @@ def _data_files():
         yield _dirname(mo), [mo]
 
     yield 'share/applications', ['share/applications/solaar.desktop']
-    yield 'share/solaar/udev-rules.d', ['rules.d/42-logitech-unify-permissions.rules']
+    yield 'lib/udev/rules.d', ['rules.d/42-logitech-unify-permissions.rules']
     yield 'share/metainfo', ['share/solaar/io.github.pwr_solaar.solaar.metainfo.xml']
 
     del _dirname


Test patch: