Hi Bruno,
On 3/26/24 5:20 AM, Bruno Haible wrote:
> Regarding the 'modules' subdirectory: When I see you replacing 2 lines of code
> with 8 lines of code, and especially searching for a 'modules' file name
> component, I wonder whether there's no simpler solution.
> Namely, a module of name NAME can be located at one of the following
> locations:
> gnulib_dir/modules/NAME
> local_dir1/modules/NAME
> local_dir2/modules/NAME
> ...
> (Or it can logically be in such a location but physically reside in a
> temporary
> file.)
> So, if the GLModule.__init__ method knows about which directory (gnulib_dir,
> local_dir1, local_dir2, ...) resolved the lookup from GLModuleSystem.py:108,
> it just needs to remove the /modules/ file name component from that (fixed!)
> position. I think this should be simpler than to search for a /modules/ file
> name component and then argue whether the first one found or the last one
> found is the better match.
Yes, my solution is less than ideal, I agree. I originally wanted to
change GLFileSystem.lookup to return the directory, but that would
involve changing multiple callers who do not use it. Therefore, I
decided against it at the time.
The GLFileSystem.py file returns many tuples which is very much making
me want to add type hints. It is easier to glance at and understand
that way, in my opinion.
Right now GLFileSystem.lookup returns tuple[str, bool] where the
string is the filename and bool is if the file is temporary or not.
An idea that I have currently is changing it to tuple[str, str, bool],
where the first string is the directory and the second is the module
name. This should be suitable for passing to GLModule.__init__().
The callers who need the path can construct it using:
joindir(directory, 'modules', module_name)
or something similar. I will continue thinking about it though.
Collin
