Add more command line and config options for specifying package search directories about gap HOT 8 OPEN

On Wed, Mar 04, 2015 at 08:46:11AM -0800, Max Horn wrote:

As discussed on issue #5, it is useful to have a global directory
where one places packages, so that one can point multiple GAP
instances to it, and have them share it.

Unfortunately, the only way I am aware of doing this right now is via
the -l option, by adding another root directory to GAP.

This means I cannot just create a directory my-gap-packages
somewhere and point GAP to it. Instead, I need to create a
subdirectory pkg of that, and places the packages in there, and
point GAP to the parent directory.

I do not get the point here. The -l option provides a very flexible
(and well documented) way of adding or overwriting all files read by
GAP, not just those in the pkg subdirectory.

So, I don't see what could be the advantage of being able to specify
just additional package directories. If you have a directory which only
contains GAP packages, you can give that to GAP via the -l option after
creating a link with ln -s . pkg.

Oh, and double bonus points if I were able to add additional package search paths during
runtime... ;-).

No this is no good idea. GAP uses the dependencies between all packages available at startup to determine which version of which package it should load. So, when you add packages after startup GAPs loading behaviour can be different from a restart with the additional packages. This is probably not what you want. Better restart GAP when you have changed its package setup.

from gap.

I find "-l" quite hard to use. I know a few people who have tried, and failed.

gap -h tells you it 'sets the GAP root paths', but then calling gap -l mydir just produces gap: hmm, I cannot find 'lib/init.g' maybe use option '-l <gaproot>'?.

While for advanced users I realise the ability to replace, prefix or postfix the library path might be useful, for beginners, just a simple addition is probably easier to use.

Also I used to do ln -s . pkg, but every so often some program or another would get confused -- for example you can't use scp to copy a directory using this trick from one machine to another.

from gap.

As @fingolfin wrote in the beginning of this thread, "it is useful to have a global directory where one places packages, so that one can point multiple GAP instances to it, and have them share it".

Actually, there is such directory, which is .gap/pkg (on OS X, also /Users/username/Library/Preferences/GAP/pkg and unless GAP is called with -r option, packages from this directory will be also loadable. This is equivalent to calling GAP and adding this directory using the -l option.

I am using this feature myself, though I have only some of my private packages there (for the officially redistributed packages, I prefer to update them with the new GAP installation).

from gap.

What's the status of this discussion? It seems to me that this issue may be closed since -l option and using .gap/pkg (on OS X, also /Users/username/Library/Preferences/GAP/pkg) provide necessary functionality.

from gap.

Once we have long command line options there is no problem adding things like

—prepend-gap-root-path and —append-gap-root-path if someone wants to. They might be easier to use than things with ;

I would personally also be quite tempted by a version of LoadPackage (probably with a different name) that took an
actual path rather than a package name.

Steve

On 8 Apr 2015, at 23:18, Alexander Konovalov [email protected] wrote:

What's the status of this discussion? It seems to me that this issue may be closed since -l option and using .gap/pkg (on OS X, also /Users/username/Library/Preferences/GAP/pkg) provide necessary functionality.

—
Reply to this email directly or view it on GitHub.

from gap.

@alex-konovalov I would prefer if this was not closed, as I don't consider -l a sufficient solution. IMHO, it should be possible to specify package search paths without also extending the list of GAP roots.

from gap.

Oh, and double bonus points if I were able to add additional package search paths during runtime... ;-).

No this is no good idea. GAP uses the dependencies between all packages available at startup to determine which version of which package it should load. So, when you add packages after > startup GAPs loading behaviour can be different from a restart with the additional packages. This is probably not what you want. Better restart GAP when you have changed its package setup.

Two more comments:

• I didn't remember that there is already 'ExtendRootDirectories' which causes a reinitialization of the infos about available packages. Of course, depending on the already loaded packages strange things may happen, and the behaviour can be different from a newly started gap.
• There is also 'SetPackagePath' to force the use of a specific copy of a package (if not yet loaded).

from gap.

@fingolfin I suggest to re-assign this to a future milestone (4.9.1 or even 4.10.0).

from gap.