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. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
