Plugin Package Paths

Plugin Package Paths

[Peter Polidoro]

What is the proper way to package plugins when a packaged program 
searches for them in the executable path rather than the profile 
path?

I would like to package plugins for two programs, kicad and 
freecad, and they both search for plugins by first finding the 
path of the executable. Freecad uses /proc/self/exe and kicad uses 
wxStandardPaths::GetExecutablePath. This seems to cause them to 
look for plugins in the package path in the store rather than the 
profile path.

What is the proper way of handling this when packaging plugins? 
Should the package of the main program modify the source code to 
find the path of the executable using the environment variable 
GUIX_ENVIRONMENT rather than /proc/self/exe or 
wxStandardPaths::GetExecutablePath? Or can these calls be tricked 
with hard links somehow? Or is there some other better way of 
dealing with this?

These programs also search for plugins in the user home directory, 
but would using those require using system containers?

Re: Plugin Package Paths

[Maxim Cournoyer]

Hi,

Peter Polidoro <peter@polidoro.io> writes:

> What is the proper way to package plugins when a packaged program
> searches for them in the executable path rather than the profile path?
>
> I would like to package plugins for two programs, kicad and freecad,
> and they both search for plugins by first finding the path of the
> executable. Freecad uses /proc/self/exe and kicad uses
> wxStandardPaths::GetExecutablePath. This seems to cause them to look
> for plugins in the package path in the store rather than the profile
> path.
>
> What is the proper way of handling this when packaging plugins? Should
> the package of the main program modify the source code to find the
> path of the executable using the environment variable GUIX_ENVIRONMENT
> rather than /proc/self/exe or wxStandardPaths::GetExecutablePath? Or
> can these calls be tricked with hard links somehow? Or is there some
> other better way of dealing with this?

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,
Maxim

Re: Plugin Package Paths

[Peter Polidoro]

Maxim Cournoyer <maxim.cournoyer@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?

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?

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?

Re: Plugin Package Paths

[Maxim Cournoyer]

Hi Peter,

Peter Polidoro <peter@polidoro.io> writes:

> Maxim Cournoyer <maxim.cournoyer@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