Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set package search paths independently from GAP roots #933

Closed
wants to merge 1 commit into from

Conversation

fingolfin
Copy link
Member

This is work-in-progress code which I started in February, but then got sidetracked, and never completed.

Before I invest more effort into it, I thought I should ask what people think about this...

This PR is about changing GAP to tracker "package search directories" separately from "GAP roots"

The idea is that I would like to be able to tell GAP to load packages from a specific dir, and not just from a "foo/pkg/my-actual-package", where "foo" must be a GAP root, and "pkg" is fixed (GAP insists on it). Instead, I'd like to be able to just point GAP at a directory "foo", and it automaticaly picks up any packages in there -- regardless of whether "foo" itself is the directory of a package, or "foo" contains packages (such as "foo/cvec", "foo/orb", ...).

Of course one can still specify GAP roots; internally, when you specify a GAP root "foo", then GAP simply adds "foo/pkg" to the list of package search directories. But in addition, users should be able to specify package search directories which are not within a GAP root. Either by calling the GAP function ExtendPackageDirectories(), or by specifying a command line flag (the latter has not yet been implemented).

Of course if anybody is interested in this, feel free to help work on it... or just give feedback... :)

@fingolfin fingolfin added kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) labels Nov 3, 2016
@codecov-io
Copy link

codecov-io commented Nov 3, 2016

Codecov Report

Merging #933 into master will decrease coverage by <.01%.
The diff coverage is 34.61%.

@@            Coverage Diff             @@
##           master     #933      +/-   ##
==========================================
- Coverage    74.6%    74.6%   -0.01%     
==========================================
  Files         481      481              
  Lines      242402   242427      +25     
==========================================
+ Hits       180851   180858       +7     
- Misses      61551    61569      +18
Impacted Files Coverage Δ
lib/system.g 67.28% <100%> (+0.15%) ⬆️
lib/package.gi 69.38% <32%> (-0.44%) ⬇️
hpcgap/lib/hpc/stdtasks.g 63.68% <0%> (-0.26%) ⬇️

@olexandr-konovalov olexandr-konovalov added this to the GAP 4.9.0 milestone Nov 17, 2016
@olexandr-konovalov
Copy link
Member

I think this may be useful - for example, this would make life easier when one runs GAP docker container and would like to load GAP package from their local filesystem. I suggest to review this in order to include in GAP 4.9.

@fingolfin
Copy link
Member Author

To finish this, there should also be a command line option similar to -l but for package dirs instead of GAP roots. See also issue #12

@olexandr-konovalov
Copy link
Member

@fingolfin this seems not be ready for GAP 4.9.0 - let's postpone to some future milestone.

@fingolfin fingolfin removed this from the GAP 4.9.0 milestone Nov 3, 2017
@fingolfin
Copy link
Member Author

@alex-konovalov well, you added that milestone, I never had that in mind :-). Removed it.

@olexandr-konovalov
Copy link
Member

@fingolfin ok. That was just an "add that milestone to remind us to review the status of this PR before making GAP 4.9 beta" intention.

This is a first step towards allowing package directories to be
specified independently from GAP root paths.
@fingolfin
Copy link
Member Author

Closing in favor of PR #5873

@fingolfin fingolfin closed this Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants