[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] PyArch/PyBaz road map
From: |
David Allouche |
Subject: |
[Gnu-arch-users] PyArch/PyBaz road map |
Date: |
Sat, 07 May 2005 18:06:33 +0200 |
On Sat, 2005-05-07 at 08:44 -0500, John A Meinel wrote:
>
> If it doesn't take too much of your time, could you post at least an
> outline of what would need to change to the Wiki?
> Also, for me, there is no need for "incremental" changes. If there is a
> clear-cut superior version, I think it would be best to get it
> implemented quickly, and not make people incrementally fix their layers.
>
> You're welcome to tell me I'm off base, but I have the feeling pyarch
> isn't heavily utilized right now. And while I understand your desire to
> not maintain it with bzr coming, I think having something above tla
> would still be good. Especially since bzr != Arch, even if they are close.
I would do this if there is interest in PyArch beyond "I do not need it,
but it would be nice to have".
The first thing to do would be to merge pybaz back into PyArch, since a
lot of cleanup and better infrastructure has been done there. Some of
the of the planned changes are in the TODO of PyBaz.
Off the top of my head the needed changes would include:
* Remove the deprecated methods and various backwards
compatibility hacks. Rename iter_* methods by removing the iter_
prefix, but still use iterators pervasively.
* Remove the SourceTree class, it's just crack.
* Remove all subclassing of str.
* Generalise the use of Factory to make subclassing by client code
convenient.
* Remove the insane NamespaceObject hierarchy in favour of just
Revision, Branch (currently Version), Location (currently
Archive), and BranchCollection.
* Design a way to accomodate both old style Locations (registered
names) and new style ones (urls as used in Baz).
* Separate out revision library handling from the namespace
objects. Probably also separate out cachedrev handling, there is
not a good separation between domain objects and implementation
knobs.
* Change the NameParser API to be consistent with the API changes
in the rest Pybaz. Also, no longer do implicit default-archive.
* Simplify the process handling subsystem, that has about 3 or 4
layers of cruft built in.
* Continue with splitting the code into small modules.
* Convert the test suite to the new fixture framework.
* Remove the _baz.py (or _tla.py) module and use the "self._impl"
pattern everywhere for version-dependent behaviour.
* Redesign things like inventory and commit that need to many
parameters.
* Redesign incremental output parsing to not require use of
isinstance().
* Provide an asynchronous API. That would require depending on
Twisted or writing a new asynchronous process handling framework
(twisted process handling is not really up to par).
* Redesign most of the API to unify return values as lists,
iterators, or callbacks.
And that's just a quick brain dump...
--
-- ddaa
signature.asc
Description: This is a digitally signed message part
- Re: [Gnu-arch-users] Octopy patches for nested tree view, David Allouche, 2005/05/03
- Re: [Gnu-arch-users] Octopy patches for nested tree view, John A Meinel, 2005/05/04
- [Gnu-arch-users] Regarding pyarch future, Mikhael Goikhman, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, David Allouche, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, John A Meinel, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, Mikhael Goikhman, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, Rene Schallner, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, Mikhael Goikhman, 2005/05/08
- Re: [Gnu-arch-users] Regarding pyarch future, David Allouche, 2005/05/11
- Re: [Gnu-arch-users] Octopy patches for nested tree view, Rene Schallner, 2005/05/08
- Re: [Gnu-arch-users] Octopy patches for nested tree view, David Allouche, 2005/05/11
Re: [Gnu-arch-users] Octopy patches for nested tree view, Yasushi Saito, 2005/05/04