On Fri, 2005-05-06 at 00:38 +0200, Rene Schallner wrote:
On Thursday 05 May 2005 10:56, David Allouche wrote:
I would like that to happen (actually, octopy was one the projects that
prompted the creation of pyarch in the first place), but I would not
encourage it.
PyArch has gone obsolete, as my focus in now on Bazaar, and PyBaz itself
has little future.
http://udu.wiki.ubuntu.com/PybazAndBzr
If someone proposes improvements in pybaz, I will try to be more lenient
in the next monthes since long term maintainability goals are now
essentially void.
Now it is getting tricky. For higher level user interfaces written in
python (not necessarily GUIs), this is a bad situation:
pyarch got obsoleted in favour of pybaz (for bazaar).
pybaz will soon get obsoleted in favour of "bzr" (for bazaarNG).
(Note how it's all bazaar's fault :) )
Not entirely. I did not do a very good job at keeping the PyArch code
base pleasant to work with. It's full of cruft, and does some outright
stupid things. It would be possible to evolve it into something cleaner,
but that would involve a lot of tedious work and many incremental API
changes.
So there is a significant cost in maintaining PyBaz and evolving it into
something better. With bzr on the horizon, it's just not worth the
trouble. However it's still going to be around for a few months, and
should somebody volunteer to take over the release process, I have a
fairly clear idea of how it should evolve.
One of the reasons PyArch got deprecated is that TLA makes it quite
difficult and annoying to maintain a wrapper compatible with multiple
versions. Part of the problem is the absence of a readily usable version
string. Another part of the problem at the time was the absence of a
release process, so I ended having to stick in features that were only
supported in non-mainline branches.
Finally, proper support for baz was bound to require incompatible API
change to accommodate model changes. Ironically, these changes start
being needed now with the new archive registration and support for
debian version ids.
Hmm. When thinking about John's suggestion: Would it be wise to
re-animate pyarch? Are there other python bindings for tla? Ones that
are actively maintained?
There are no other python bindings that I'm aware of. Actually, there
are no other _generic_ language bindings for Arch that I'm aware of.
What makes PyArch difficult is it tries to be generic. By focusing on
the specific needs of an application (like ArchMagic, perl, or xtla,
elisp) you make the problem a lot simpler.
I think, for the near future, I'll stick to octopy's version of pyarch and
change it if needed. As for baz, I might get away with a minimal amount
of changes to the existing code by making the name of the tla executable
configurable (and some command / parameter names that go with it as well).
Supporting multiple command-line backend is probably more tricky a
problem than you think. Here is a little brain-dump:
* You need to detect which version of the command-line tool you
are using
* baz makes that trivial
* tla makes that a bit tricky since:
* the --version output format keeps changing
* there is no clear-cut "latest" tla. Historically
it was something like 1.1, 1.2, 1.2.1,
1.2.2-pre2, 1.2 (again), 1.3, 1.4pre1, 1.3.1,
etc. (I might recall incorrectly)
* But the situation is improving since community
development is now happening on baz, so there is
no longer a problem with non-mainline branches
being in widespread use.
* You need to adjust the command-line arguments according to the
version your are using, baz is very different from tla for
frequently used command.
* You need to work around bugs specific to each version.
* Some features are not available in all versions, and would
warrant API support. For example baz explicit conflict handling,
new archive registration scheme, evolving namespace syntax,
arch-cache.
But all in all, it's not that difficult as long as you stay focused on
the needs of a specific application and target only a few current
releases of the command-line tools.
Hopefully I have not discouraged you from the valuable endeavour of
maintaining a Arch GUI that does not suck. I just meant to share some of
the experience I have accumulated working on PyArch and PyBaz.
signature.asc