Collin Funk wrote: > For CI, I am thinking it is best to ignore the typing warnings for the > time being. Since gnulib-tool.py needs a bit more refactoring for that > to be helpful. It was written before typing was a thing. :)
Hmm. Is that refactoring, that you are imagining, intrusive? If it's intrusive, then maybe we should leave it alone. You already introduced types in the function signatures and in the fields of classes; what else is missing? > I'm removing the 'lines_to_multiline' import from GLImport.py. We > could have a few checks for guaranteed runtime failures like this: > > $ mypy GLImport.py | grep 'name-defined' > GLImport.py:722: error: Name "lines_to_multiline" is not defined > [name-defined] > GLImport.py:736: error: Name "lines_to_multiline" is not defined > [name-defined] > GLImport.py:1143: error: Name "lines_to_multiline" is not defined > [name-defined] > GLImport.py:1326: error: Name "lines_to_multiline" is not defined > [name-defined] > GLImport.py:1327: error: Name "lines_to_multiline" is not defined > [name-defined] > GLImport.py:1328: error: Name "lines_to_multiline" is not defined > [name-defined] Sounds like a reasonable way to automate this check... > I'm not too familiar with the GitLab CI stuff. Would a Makefile in > gnulib/pygnulib with some checks work? Yes, a Makefile in pygnulib/ would be sufficient. The top-level Makefile then may invoke it. Bruno
