[pygnulib] gnulib-python initial merge and some minor bug fixes

[Dmitry Selyutin]

Hello,

this is the very first patch after five years of silence.
It all boils down to importing gnulib-python github repository[0] as is.
I'm going to import everything except of pygnulib/testing.py.
The second patch (hotfix.patch) just includes some quick fixes.

The development is going to happen inside a standalone branch.
Once stuff becomes mature enough, it'll be pushed into the master.

[Dmitry Selyutin]

Sorry, I've forgotten to provide a link to the original repository.

[0] https://github.com/ghostmansd/gnulib-python

Post by Dmitry Selyutin
Hello,
this is the very first patch after five years of silence.
It all boils down to importing gnulib-python github repository[0] as is.
I'm going to import everything except of pygnulib/testing.py.
The second patch (hotfix.patch) just includes some quick fixes.
The development is going to happen inside a standalone branch.
Once stuff becomes mature enough, it'll be pushed into the master.
--
With best regards,
Dmitry Selyutin

[Dmitry Selyutin]

P.S. Please ignore binary .pyc files; they won't be present in the commit,
just a leftover from the testing.

Post by Dmitry Selyutin
Sorry, I've forgotten to provide a link to the original repository.
[0] https://github.com/ghostmansd/gnulib-python

Post by Dmitry Selyutin
Hello,
this is the very first patch after five years of silence.
It all boils down to importing gnulib-python github repository[0] as is.
I'm going to import everything except of pygnulib/testing.py.
The second patch (hotfix.patch) just includes some quick fixes.
The development is going to happen inside a standalone branch.
Once stuff becomes mature enough, it'll be pushed into the master.
--
With best regards,
Dmitry Selyutin

--
With best regards,
Dmitry Selyutin

[Bruno Haible]

Hi Dmitry,

Post by Dmitry Selyutin
It all boils down to importing gnulib-python github repository[0] as is.
I'm going to import everything except of pygnulib/testing.py.
The second patch (hotfix.patch) just includes some quick fixes.

In case you are waiting for an approval: I approve.

Bruno

[Bruno Haible]

Hi Dmitry,

Post by Dmitry Selyutin
The development is going to happen inside a standalone branch.
Once stuff becomes mature enough, it'll be pushed into the master.

I would like to make it easy for users to invoke gnulib-tool.py
for users, without changing their autogen.sh / bootstrap / Makefile.devel /...
scripts or recipes. I'll do this by introducing an environment variable,
say, GNULIB_TOOL_PYTHON so that people can do

$ GNULIB_TOOL_PYTHON=yes ./autogen.sh

instead of

$ ./autogen.sh

This will be a couple of lines of code in gnulib-tool, to invoke
gnulib-tool.py with the same arguments.

The prerequisite for this is only that gnulib-tool.py is properly
invokable through python or python3, and that it sits in the 'master'
branch. It is *not* a requirement that it is "mature enough".

Bruno

[Dmitry Selyutin]

Hi Bruno,

what do you think if I'll periodically merge stable versions into the
master? For example, I think currently the imported 'as is' version can be
merged. I'd like to work on API on a separate branch though, since I
roughly dislike the idea of developing on master.

For example, see my latest commit; even though it does not affect the API
yet, these classes (and similar stuff) are going to replace all this mess
with setters and getters, and when it will begin to happen, I don't want to
break the current gnulib-tool.py (even though it is considered to be
experimental yet).

P.S. I've just started doing the very same thing around Config class that I
had done five years ago, but previously it had taken approximately 1000
lines more than now. Wow, just wow.

21 авг. 2017 г. 11:36 ПП пПльзПватель "Bruno Haible" <***@clisp.org>
МапОсал:

Hi Dmitry,

Post by Dmitry Selyutin
The development is going to happen inside a standalone branch.
Once stuff becomes mature enough, it'll be pushed into the master.

I would like to make it easy for users to invoke gnulib-tool.py
for users, without changing their autogen.sh / bootstrap / Makefile.devel
/...
scripts or recipes. I'll do this by introducing an environment variable,
say, GNULIB_TOOL_PYTHON so that people can do

$ GNULIB_TOOL_PYTHON=yes ./autogen.sh

instead of

$ ./autogen.sh

This will be a couple of lines of code in gnulib-tool, to invoke
gnulib-tool.py with the same arguments.

The prerequisite for this is only that gnulib-tool.py is properly
invokable through python or python3, and that it sits in the 'master'
branch. It is *not* a requirement that it is "mature enough".

Bruno

[Bruno Haible]

Hi Dmitry,

Post by Dmitry Selyutin
what do you think if I'll periodically merge stable versions into the
master?

This is an even better habit than the "test once then push" habit that
we otherwise use on gnulib.

Post by Dmitry Selyutin
For example, I think currently the imported 'as is' version can be
merged.

Cool! I'll then make the mentioned change to gnulib-tool and add something
about it to the docs.

Post by Dmitry Selyutin
P.S. I've just started doing the very same thing around Config class that I
had done five years ago, but previously it had taken approximately 1000
lines more than now. Wow, just wow.

Yes, it takes experience to write elegant code :-) But _elegant_ code was
not among the requirements five years ago.

Bruno