Hi Peter, Peter Polidoro <pe...@polidoro.io> writes:
> Maxim Cournoyer <maxim.courno...@gmail.com> writes: > >> These programs should be patched to honor e.g. FREECAD_PLUGINS_PATH >> or >> similar. Then a 'native-search-path' specification can be attached >> to >> the freecad packaged, and finding freecad plugins will happen in any >> profile. >> >> The FREECAD_PLUGINS_PATH should be written with the intent of >> upstreaming it (sharing it for inclusion with upstream), as that >> should >> be valuable to other distributions/scenarios as well. > > Thanks. I have reached out to both the kicad and freecad communities > about adding support for environment variable options in the search > paths, but so far people from both communities seem skeptical. > > Do you know of any examples of other projects doing this properly in > Python and C++ that I can show to these communities? Developers only accustomed to file hierachy standard (FHS) systems will indeed need some rationale to be convinced. I think snapcraft may be an environment where such support could be useful, I'm not so sure. At least NixOS is another non-FHS system that would benefit from a plugins search path. > Both programs search for the executable path, then base other system > search paths relative to this root path. In general, do you think it > is better to use an environment variable to set the root to the > profile directory or to be more narrow and just specify the plugin > path or paths if the program uses more than one? In general it's better to be precise; this way the search paths in Guix can match only what's needed, and it means less scanning of the file system to do. > I am guessing it may take a while, if ever, to get such changes > included in the upstream projects. In the mean time, is it considered > bad practice to attempt to just patch the source code in the Guix > package? In the mean time it's OK to have them live as patches in the Guix tree, as they are needed :-). -- Thanks, Maxim
