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
_______________________________________________ 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/
