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

[John A Meinel]

David Allouche wrote:
> 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.

I think a lot of it is if we could define what "Arch" is. I know it was
mentioned in the past about writing actual documents. I think we could
discuss on the list, but probably as Migo says #arch might be better.

Stuff like: archives, working trees, namespaces, etc.

Once you get it back down to what the basics are, then you can start
creating meaningful set of functions/objects, and use the _impl pattern
to instantiate things based on the backend.

I think it would be a good thing to talk about, and it would lead to a
nice generic abstraction. I certainly have my thoughts on it, but I
haven't written any of the wrappers over top, which gives a different
perspective.

> > 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.

Exactly, the abstraction needs to be based on "what is Arch", which to
date is not defined terribly well. I'm guessing Tom has a pretty strong
idea in his head, and Lifeless has a slightly different one in his.

> 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.

Can you give specific examples of how it is a better model? I've tried
to look through the documents, and while I don't agree with everything
that is said, it still seems interesting.

John
=:->

> 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.

signature.asc
Description: OpenPGP digital signature