On 4/16/24 6:35 PM, Bruno Haible wrote: > This does not make sense. GLConfig is meant to hold settings and > configuration, > nothing more. > > I see the home of this function more in GLFileSystem.py. Maybe in class > GLFileAssistant, maybe in a new class in that same file.
Hmm, thanks for the advice. At the moment I think GLFileAssistant makes sense. Since it performs transformations on the files based on their categories, transforming the path names seems somewhat in its domain. This will require some code reordering first though. The GLFileAssistant used by GLImport is not defined until GLImport.execute(). The file name transformations are done in GLImport.prepare(). This function also returns the transformers used by GLFileAssistant.__init__(). I think the correct solution there is to define the GLFileAssistant in GLImport.__init__() with it's default arguments and then set them later. I've been meaning to do this anyways because I find defining things outside of __init__ makes things harder to follow. This was also a reason I had in the back of my head when fixing the default arguments here: https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00228.html > 'tests=lib/' should not occur in the scope of mode == 'copy-file'. > But this string is an indicator inside gnulib-tool; users of gnulib-tool > should not be allowed to pass it. Okay I see. I'll leave it as-is now since it works and I rather not do accidental replacements. :) Collin