Hi Dmitry, all, First of all, my deepest apologies for not having pulled your gnulib-tool rewrite into gnulib once you finished it. The reason was simply that the project went from April to September 2012, and I stopped having time for GNU in July 2012. I only "came back" recently.
If there's one thing I learned in that time, it is that I get nowhere if I don't set priorities (which projects to work on) for myself. My priorities are set for the next year or so, and they include only _occasional_ contributions to gnulib. Therefore I can not do this integration myself, but I can help out with guidance. In any case, I'm in favour of integrating it into gnulib. > I'm amazed that someone still remembers this project. Looking at its > sources, I see that there is room for improvement, but still the overall > project structure may still be integrated into gnulib. I would be glad to > continue working on the project in my free time, This would be ideal! > though my Python skills are a bit rusty. The good thing about Python is that even with superficial knowledge of the language, you can read and maintain code. > As for parallelization, I think it may be a good idea to > use Python 3 since it now has some form of Go-like coroutines IIRC. Huh? I thought I insisted that we use Python 3 from the beginning. Anyway, I think no one will be asking for parallelization once they use gnulib-tool.py. > Do you think it's a good idea to revive the old project? It seems that it > may still be useful. Yes, sure. I think the biggest lack, currently, is that there is no test suite that would guarantee behavioural compatibility between the shell script and the python program. But this is not a blocker; it can be mitigated by having the gnulib users test one versus the other. And once enough users are satisfied with the python program's results, it can be declared the "official" one. So, if you (or someone else) volunteers to work on this integration, I would see the sequence of actions as: 1. Merge https://github.com/ghostmansd/gnulib-python into gnulib. 2. There were 52 modifications to gnulib-tool since April 2012. Do the same modifications to gnulib-tool.py, for consistency. (Most of these changes were quite small. The biggest one is the one from 2015-11-21.) 3. Document how to use gnulib-tool.py, but mark it experimental. 4. For several months, answer support requests from users. 5. Once a sufficient number of users have used it and are satisfied with it, document it as recommended and make it the default. Bruno