Hi Mathieu, > Sorry, I was unaware of that branch. What about adding some information > about the gnulib-tool.py development process in a "README-hacking" file? Frankly I don't know what to write here yet. :-) I mean that there must be something already to play with, but the whole thing is too half-baked to even mention it on the master branch.
> Since there is no "gnulib-tool.py" nor unit tests for the pygnulib > module in that branch how are you working on it? with the REPL? Am I > overlooking something? I really do have a simple script which is going to become a new gnulib- tool.py. I've just committed it; it already can successfully parse the whole bunch of command-line options (except for some corner cases) and recently I could even teach it do do the same transitive closure the original script does upon modules import. :-) I've just committed it; please check the pygnulib.py from the python branch. > I would be happy to get involved in this development which will a good > excuse for improving my Python skills. Well, I'm also not a Python guru; even though I know Python much better than I knew it when I started rewriting the gnulib-tool for the first time, I'd be really glad if we could learn from each other. > Given that the "python" branch seems like a full rewrite of the pygnulib > module, there is not much interest in applying my patch. There's nothing wrong with the patch itself, it's correct and does the right thing, but I really think that it would be a lot better to invest your time into a new implementation. Especially if you want to train your Python skills, because the old code may really teach you some bad developer practices. -- With best regards, Dmitry Selyutin
signature.asc
Description: This is a digitally signed message part.