Re: [gnulib-tool-py] Module does not exist: error or warning?

[Bruno Haible]

Hi Dmitriy,

> I began to write a code for getting modules from cache, combining them with
> user-defined modules and then processing them using different functions.

So, you have already the layer equivalent to func_lookup_file ?
That seems like it would be worth to have a class that implements a
"virtual" file system.
- Members: the value of the --local-dir option.
- Methods:
  - A method to return the contents of a file with given name.
  - A method to list/enumerate all subdirectories of a given directory.
  - A methid to list/enumerate all files (recursively) of a given directory.

For example, if gnulib's dir contains files
    A1
    A2
    modules/B
    modules/U/C
and the directory pointed to by --local-dir contains files
    A2.diff
    A3
    modules/B.diff
    modules/D
    modules/U/C2

then the combined "virtual" file system will contain the files
    A1                 (from the first dir)
    A2                 (from the first dir, patched by A2.diff)
    A3                 (from the second dir)
    modules/B          (from the first dir, patched by modules/B.diff)
    modules/D          (from the second dir)
    modules/U/C        (from the first dir)
    modules/U/C2       (from the second dir)

> And first of all I've created checkModule method, which returns True or
> False depending on whether module was found in either gnulib root directory
> (DIRS['root'] from constants) or localdir directory. We have a couple of
> methods that normally shall test module name when we add a module (see
> addModule/addAvoid, removeModule/removeAvoid, setModules/setAvoids,
> resetModules/resetAvoids methods). Such methods should normally do
> something if module does not exist.

Yup. The old gnulib-tool uses the function func_verify_module to verify
a module name.

> I can see three possible variants:
>   1. We can move code where such things can happen to run(self) method (or
> method with similar name, I haven't decided yet). If error happens, we
> catch it and then print warning that module was not found (just look to m4
> package to see an example where package has 'exit' method which does not
> exist).
>   2. We can use warnings module, which is default module for Python.
> However, it has one disadvantage: Python provides ugly mechanism to catch
> them, so I'd rather prefer to raise an error instead of generating a
> warning.
>   3. We can simply print a message instead of generating error. This way is
> the easiest, but some users who wants to make their own scripts would
> rather prefer to catch errors or leave them when they create new class
> which is based on the GNULibImport class (if they need to have such class).
> 
> I'd rather prefer the first method, because we can save users a possibility
> to catch errors or not as they like in their scripts.

Based on your description, option 2 does not integrate well with exceptions,
so discard it.

In the old code, the place where an invalid module name is detected is
near to the code which signals a warning (your option 3). This is purely
because there's no exception handling in 'sh' script.

I'd suggest that you use the standard mechanism for exception handling of
Python. This will give us the most choices in the long run. If it does not
match the current behaviour of the old gnulib-tool, it does not matter much.
I think this approach is what you describe in 1. ? (I haven't fully
understood.)

Bruno