Re: [Gnu-arch-users] Regarding pyarch future

[David Allouche]

On Sun, 2005-05-08 at 12:57 +0000, Mikhael Goikhman wrote:
> I would like to comment on this pyarch message, but I will not do it
> deeply, mainly because I don't think this media is appropriate for such
> discussions. Sitting on a narrowly focused #arch-frontends and rolling
> these issues, like we did for some months (until the python side people
> decided to leave), is significantly more effective.
> 
> Regarding support for multiple arch versions. This may be done by
> implementing a global module that detects and parses the arch client
> name + version, and has full knowledge about feature sets of all known
> flavours. It may export predicates like is_baz and has_file_diffs_cmd.
> Here is a sample implementation of this idea:
> 
>   http://migo.sixbit.org/software/arch-perl/manpages/Arch::Backend.html
> 

That's essentially the way it is done in the (deprecated) arch._tla and
pybaz.backends.baz modules, and in the (current) _impl classes in PyBaz.

The latter design pattern is superior because it provides better source
code locality. It does not really have a name, it appears to me like
something in-between a Bridge and a Strategy, with bits of Template
Methods thrown in.

> One fancy point in your message is dismissing arch-perl from the list of
> arch bindings just because it is built up-to-down. Personally, I believe
> that such approach besides being more useful may lead to a better design.

I agree. Some problems in PyArch are a consequence of trying to infer
abstraction from the tla command set, instead of inferring it from use
cases.

arch-perl was not considered because (as I understand it) it's not
something that aims at being generally useful without substantial
extension by users. But experience shows that PyArch failed to achieve
that level of generality.

> I am sure you agree that a mere duplication of the tla or baz command set
> is not the best thing to do, many commands (including new 'baz' commands)
> are high level ones that it makes sence to implement natively. The native
> implementations may be more efficient and much more functional. This is
> currently true, for example, for baz annotate versus arch-perl annotate.

Right now, yes.

However we are at a turning point, and it is not clear at all whether
GNU Arch will stay as it is now, whether it will evolve in the direction
of Baz-NG, or whether it will evolve in a different direction. I have no
alloted work time and no personal desire to try to bridge the gap
between these diverging models.

My focus on Baz-NG is not merely a consequence of corporate policies.
I personally regard it as a superior model and I am confident in the
author's ability to deliver a tool whose design it as least as good as
Arch, and which provides a superior user experience. The time has come
to draw from the experience of all the existing free distributed version
control systems, GNU Arch being the best of them, and do to something
better and legacy-free.

The existing code base will be useful to me in the short term. In the
longer term, scripting Baz-NG will be done more effectively without the
Arch legacy.

I also have to point out that this says nothing about the future of the
current Bazaar implementation. Robert Collins plans to evolve it into an
alternative, Arch-compatible, Bazaar-NG implementation.

> In any case, I am ready to cooperate and discuss the ideas (not on this
> list) with whoever continues with pyarch. Note that currently arch-perl
> combines equivalents of pyarch, pybaz, pylon (by Aaron) and a number of
> useful utility classes for frontends, plus some things from your posted
> TODO, minus dubious design. I seriously want Python to have useful arch
> bindings, Arch may win from this. A lot of hard work is required though.

It just needs more interest than "it would be nice to have, but I'm not
going to need it". Nobody has stepped in so far, if that would happen,
I'm sure the volunteer would find good support from the Arch community.

-- 
                                                            -- ddaa

signature.asc
Description: This is a digitally signed message part