bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pygnulib: code separation


From: Dmitry Selyutin
Subject: Re: pygnulib: code separation
Date: Sat, 11 May 2013 03:45:55 +0400

Hi Karl,

that's why I've called it "proposal". :-) Critics are really accepted,
since our project is mature enough to not admit such changes without
discussions.

I've thought about the future replacement since it was the goal of
Google Summer of Code (to reimplement gnulib-tool in Python), but I
don't think it will happen quickly (if it ever supposed to happen).

There is other way which we can follow, and after your advice and
critic I think it could be even better to follow this way.

We can reduce my repo exactly to contain pygnulib module and sometimes
update it if necessary inside gnulib repo (or we can even leave
decision to users: if they want to use pygnulib, they can get it from
pygnulib repo). The name of this gnulib-tool.py will be still the
same, however, I'll make an application with similar functions but
with other name (e.g. gnulib-manager) and other idea of updating. I'm
sure for some people ability to save gnulib like an "eternal"
directory on the system, for which they can easily get update, is
really a useful feature.

Thanks again for your notes and critics!

2013/5/11, Karl Berry <address@hidden>:
> Hi Dimitry (and all),
>
> I don't like to be so negative, but ... I was not aware of any general
> agreement on replacing the current gnulib world with a Python-based
> world.
>
>     Note that gnulib-tool now will be the name for the gnulib-tool.py.
>
> It seems to me that gnulib will become completely unusable for me after
> things like this are done.
>
>     directory inside user's entire machine (e.g. to /usr/share/gnulib).
>     Also copy doc subdirectory to /usr/share/doc.
>
> I know it was just an example, but using /usr is certainly wrong.
>
>     4. Copy gnulib-tool to /usr/local/bin directory.
>
> This seems to be suggesting, merely in passing, a fundamental change in
> the way gnulib is intended to be used.
>
> Maybe you should fork gnulib into pygnulib and maintain it as you like
> there, and people who like it can use it, and those of us who have a
> whole development structure built up around how gnulib is now can keep
> using it as it is?
>
> Best,
> k
>


-- 
With best regards,
Dmitry Selyutin

E-mail: address@hidden
Phone: +7(985)334-07-70



reply via email to

[Prev in Thread] Current Thread [Next in Thread]