Normalize package paths to always contain a trailing slash

[zickgraf]

SetPackagePath always appends a trailing "/" to the installation path of a package while AddPackageInfos did not before this PR. This could lead to the following error:

gap> SetPackagePath( "cap", GAPInfo.PackagesInfo.cap[1].InstallationPath );
gap> LoadPackage( "CAP", false );
true
gap> ExtendRootDirectories( [ "/tmp/some/dir" ] );
gap> SetPackagePath( "cap", GAPInfo.PackagesInfo.cap[1].InstallationPath );
Error, another version of package cap is already loaded at .../lib/package.gi:1752
brk> GAPInfo.PackagesLoaded.( pkgname )[1];
".../.gap/pkg/CAP_project/CAP/"
brk> pkgpath;
".../.gap/pkg/CAP_project/CAP"

i.e. an error is signaled because the installation path differs by a trailing slash.

This PR does two things to prevent this:

1. It normalizes the installation path in AddPackageInfos to also include a trailing slash.
2. It uses Directory in the comparison which triggers the error.

Both changes would fix the error on their own, but I think both are sensible in general:

1. Being consistent is always a good thing.
2. pkgpath is a user input, so normalizing it is a good idea anyway (as users might enter paths including "~" or with or without trailing slashes).

Text for release notes

none

[ChrisJefferson]

This seems fine to me in principle, but I'll be honest I've never used SetPackagePaths or ExtendRootDirectories. Some tests for this, perhaps in testinstall/package.tst using the existing mockpkg might work?

[zickgraf]

This seems fine to me in principle, but I'll be honest I've never used SetPackagePaths or ExtendRootDirectories.

Background: I use SetPackagePath to enforce loading packages from the user root dir in the CI, and our Julia package CapAndHomalg.jl uses ExtendRootDirectories to add its own root with our packages.

Some tests for this, perhaps in testinstall/package.tst using the existing mockpkg might work?

Done!

[fingolfin]

I'd rather not do this, nor add tst/pkg. Instead, we could create a temporary directory somewhere, then add a pkg subdir into it and into that a symlink to mockpkg.

[zickgraf]

Two questions:

1. Can we rely on IO_symlink in the test? If not, I guess things might get messy.
2. What about Windows, would IO_symlink work there? Or can we somehow exclude this test on Windows?

[ChrisJefferson]

In simple terms, you can assume everything unixy will work in Windows. I'll be sure to double check any test, but I just tried and IO_symlink works fine.

[fingolfin]

I would not rely on IO_symlink, which may not always be available (if IO is not compiled). You could simply use Exec("ln -sf FOO BAR"), or if you want to be able to detect errors, then use Process (and if anyone wants a nicer alternative, comment on #5103 ???)

[zickgraf]

I have pushed a solution using Exec. If an error occurs, ValidatePackageInfo right after the Exec will fail saying that the file is not readable, so I think there is no need for an additional error check .