That is an interesting point, maybe there is already another environment variable that could work.
I will have to look the KiCad source code, but how does it know to look in:
/usr/share/kicad/scripting
Is the root path a hardcoded value is is that set by some general Linux environment variable?
It has a default value but can be overridden by setting the KICAD_DATA variable during compile-time, which I guess if you are working with weird system package managers you’re maybe also willing to compile your own KiCad 
Note that you do need a feature request for color themes as I said above, not only because of the paths issue, but because the current color theme system treats color themes as mutable by default (like other settings files) if they weren’t installed by the PCM, but the PCM requires a read/write directory for its storage.
I realize this thread has been wandering all over the place, but thanks to everyone’s advice I think it is becoming clearer.
At this point I am just trying to figure out the bare minimum changes to put into a feature request so it is most likely to be accepted.
Compiling KiCad from source is not a problem, but these particular environment variables need to be set at run time just before KiCad starts.
So I would need to request that options for colors and other add-ons be added to the system level directories, not just scripts? I would need to request that these directories have the option to be read-only? Then I would also need to request that a new environment variable be added so the root of the system level add-ons be modified at run time, unless some other Linux environment variable can be used for this purpose?
There are already system directories for scripting plugins and for libraries; color themes are the only type of package in the PCM where this isn’t possible. So you need one feature request to support loading color themes from a read-only directory in the system data tree.
The system-level directories for data (so, not XDG_CONFIG_HOME) are already assumed to be read-only. They just don’t have a subdirectory for color themes right now.
Yes, that would need to be a separate request, but this one is simple to implement. Note that there is no system-level add-ons concept in KiCad, there is a system-level data directory that contains many things including but not limited to add-ons.
Thank you, this is starting to sound like a reasonable request hopefully.
What other data is placed into the system level data directories? Is any of that data placed by the main KiCad repository?
Do you have a recommendation for the new environment variable name?
Yes, most of it is placed by the main KiCad repo: the built-in libraries, demo files, templates, translation files, and resource files.
I wouldn’t worry too much about coming up with a name idea in your request, we can take care of that. Most likely it would be KICAD_DATA to match the CMake variable, but we’ll have to see what the other devs think.
What is a typical default value for this “KICAD_DATA” root location on a linux system? “/usr/share/kicad/“? I just want to look it up and see what the directory structure is like at that location.
The proper place to request a new feature is a gitlab issue on the KiCad repository?
Indeed, if the packager hasn’t done something else with it
Also yes
I’m not much into programming, but I guess it is pretty standard to generate custom environments for programming / testing purposes. Simplest way would be to create a new user for KiCad, but I’m sure there are more sophisticated methods. (At least for Linux).
So inside of the KiCad data directory (e.g. /usr/share/kicad), should I make it so additional plugins and other content be placed inside of a 3rdparty directory as it is in the ~/.local/share/kicad/7.0/ directory (e.g. /usr/share/kicad/3rdparty/plugins) or should plugins be in the /usr/share/kicad/plugins directory and colors and other content be placed somewhere else?
/usr/share/kicad/
├── 3rdparty
│ ├── colors
│ ├── plugins
│ └── resources
├── plugins
│ └── 3d
There is already /usr/share/kicad/scripting which is where plugins can be installed.
So we would just add /usr/share/kicad/colors probably.
We want to add the ability for you to put read-only color themes in your system, but not to put PCM packages in your system. The PCM system still will work out of a read-write directory.
Yes, that is correct, what I am asking about now is if it can be possible to have two independent ways of installing colors, plugins, and libraries. The first way would be to use the PCM to install packages into the read-write directory. The second way would be to just be to copy files and directories into the read-only system-level directories.
For colors, I need to add a feature request to add e.g. /usr/share/kicad/colors.
For plugins, just to be clear, do you mean /usr/share/kicad/scripting or do you mean /usr/share/kicad/scripting/plugins? Can there be subdirectories that contain the python files, such as /usr/share/kicad/scripting/plugins/PlaceFootprints ?
What would be the install directory name for system-level read-only libraries?
Someone beat you to it [Feature request] Support installation of color themes under /usr/share/kicad/themes (#15920) · Issues · KiCad / KiCad Source Code / kicad · GitLab
/usr/share/kicad/scripting/plugins is the place that gets searched, so you can drop a subfolder in there as you say and it should work.
/usr/share/kicad/symbols, /usr/share/kicad/footprints, etc
That is great, thank you so much for all of your help.
Might be a little confusing if the install directory is named “colors” in one location and “themes” in another. If you have a choice I would vote for consistency. The PCM colors git repository calls them “color schemes” to add another name to the mix.
I might add that next feature request for another environment variable, KICAD_DATA, or whatever, but it may not even be necessary. My package manager sets an environment variable named KICAD for the root of all of the system files in order for kicad-doc to be found. I am not sure if that is an environment variable KiCad officially supports or if it was just invented by the package manager, but it might fit these purposes.
Thanks again.
colors is the original color theme directory inside preferences. The PCM’s directory should have also been colors but this wasn’t caught, and I see little point in changing it now as doing so without some kind of migration would make people’s installed color themes disappear. “Color theme” is the official user-facing name; we can fix references to “color scheme”. I like colors better than themes because the latter is more generic; these themes are only color themes and not also icon themes, etc.
Sounds like it was invented by the package manager. Does it actually do what you want it to? A new environment variable would be necessary for run-time switching of the KICAD_DATA cmake variable.
I probably do need the KICAD_DATA variable then.
I tried putting some files into the system directories without using such an environment variable and KiCad does not seem to find them, which is probably the correct behavior.
Just to double-check though, will plugins in the system directories show up in the PCB Editor/Tools/External Plugins menu? Or will they be somewhere else? When I click on Open Plugin Directory it opens /.local/share/kicad/7.0/scripting/plugins/ so I know it is searching the KICAD7_3RD_PARTY location, but I do not know if it is also searching the system directories as well.
Is there some way of finding out which system plugin directory is being searched, like a command I can run in the scripting console to output that search path?
Yes they should. “Open Plugin Directory” will always open the user-writable one, but it searches multiple locations.
Try
import pcbnew
print(pcbnew.PLUGIN_DIRECTORIES_SEARCH)
That is a super useful command, thank you! That confirms that I will need the KICAD_DATA environment variable. I will submit a feature request on gitlab.
Does Feature request: Allow setting stock data path at runtime (#15687) · Issues · KiCad / KiCad Source Code / kicad · GitLab cover it?
It seems like that issue was created for the exact same reason, yes. I do not understand the comment about why it was closed, however. I am using Guix, not Nix, but they should both have the exact same issue of needing to be able to set that system path with an environment variable. I submitted a feature request before reading this, but you can close mine and reopen the older if you prefer.