Udev rules for dev environments

[blaggacao]

For some dev envronments, there is a use case to install udev rules for non-root device access (MODE="0666") to specific devices such as a particular arduino board.

The current nixos-specific workarround is to use services.udev.package = [ pkgs.platformio ];.

However, this does not properly encapsulate the desired state of the development shell. Maybe this ultimately falls into the same problem category as managing PKI or DNS for development environments on the host system.

Further links:

• https://wiki.archlinux.org/index.php/udev
• https://man7.org/linux/man-pages/man7/udev.7.html

  The udev rules are read from the files located in the system rules
  directories /usr/lib/udev/rules.d and /usr/local/lib/udev/rules.d,
  the volatile runtime directory /run/udev/rules.d and the local
  administration directory /etc/udev/rules.d. All rules files are
  collectively sorted and processed in lexical order, regardless of the
  directories in which they live. However, files with identical
  filenames replace each other. Files in /etc/ have the highest
  priority, files in /run/ take precedence over files with the same
  name under /usr/. This can be used to override a system-supplied
  rules file with a local file if needed; a symlink in /etc/ with the
  same name as a rules file in /usr/lib/, pointing to /dev/null,
  disables the rules file entirely. Rule files must have the extension
  .rules; other extensions are ignored.

To manipulate potential candidate destination at /run/udev/rules.d, root access seems required (who would have thought :wink:):

➜  ~ ls -la /run/udev/
drwxr-xr-x root root 160 B  Mon Dec 21 11:15:39 2020  .

/cc @CarlosLuqueC

[zimbatm]

yeah, that's rather unfortunate. I think this fits into "we need a system configuration change tool" category, which is a separate but complementary project.

[blaggacao]

Do you want me to close? Or may I suggest a delegate-to-complementary-tooling github tag for this and similar reports?

[06kellyjac]

what would delegate-to-complementary-tooling flag achieve that a script in shellHook (not sure what the equivalent is in devshell) or setting up a script in commands can't do?

[blaggacao]

My bad. Wording has been deficient. Updated my previous post. Thanks for making me realize.

[zimbatm]

Let's keep those around, it doesn't hurt to have the periphery of the project also be documented through issues like that.