[Gnu-arch-users] Regarding pyarch future

[Mikhael Goikhman]

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

There are in fact more predicates than listed here that are used mostly
in Arch::Tree class, but most of them may be currently reduced to just
is_baz, so they are not implemented. These may be added if tla will
backport these changes, or baz version x.y.z will break compatibility.
[If baz has a future at all with its new corporative plans.]

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

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.

Regards,
Mikhael.