Martin wrote:
> so what's the preferred solution for G7
>
> 1) single variable GRASS_ADDON_PATH for all components
> (as it is)
> 2) two variables - GRASS_ADDON_BASE and
> GRASS_ADDON_PATH (path only as in G6)
Glynn:
#1. Although the name doesn't matter.
If the user wants to add extra executable directories,
they can modify PATH directly.
[moving this thread over to the dev list]
as per earlier email in this thread, from my POV option #2 is the preferred solution. Definitely change the name
away from PATH for usage which isn't $PATH anymore.
if it doesn't harm to automatically prepend the $PATH,
then why not make that easy for those who want to use it?
> Martin wrote:
> > so what's the preferred solution for G7
> >
> > 1) single variable GRASS_ADDON_PATH for all components
> > (as it is)
> > 2) two variables - GRASS_ADDON_BASE and
> > GRASS_ADDON_PATH (path only as in G6)
Glynn:
> #1. Although the name doesn't matter.
>
> If the user wants to add extra executable directories,
> they can modify PATH directly.
[moving this thread over to the dev list]
as per earlier email in this thread, from my POV option #2 is the preferred solution. Definitely change the name
away from PATH for usage which isn't $PATH anymore.
if it doesn't harm to automatically prepend the $PATH,
then why not make that easy for those who want to use it?
Because it's one more unnecessary environment variable. Some systems
have a limit (4k is common) on the combined memory used by the
environment and the command line, so enlarging the environment reduces
the maximum length of a command.
A single environment variable is sufficient to find all components of
an add-on. The original idea seems to have been based upon the
assumption that an add-on would consist of a single script, with no
additional files. That assumption should be false for anything from
the add-ons repository (there should at least be a manual page).
Because it's one more unnecessary environment variable.
Some systems have a limit (4k is common) on the
combined memory used by the environment and the command
line, so enlarging the environment reduces the maximum
length of a command.
fair enough. but,
A single environment variable is sufficient to find all
components of an add-on. The original idea seems to
have been based upon the assumption that an add-on
would consist of a single script, with no additional
files.
right.
That assumption should be false for anything from
the add-ons repository
as per longer explanation in a prior email, I'd argue
that the case of the single personal script with no
support files is still at least co-equal if not the
dominant instance for addon scripts.
we hear about g.extension disproportionally because it's
a tricky cross platform dance to get it working smoothly
and folks probably don't bother us much with errors in
their personal workflows.