Re: [Gnu-arch-users] Octopy patches for nested tree view

[Rene Schallner]

sorry for not having replied sooner ...

On Friday 06 May 2005 16:16, David Allouche wrote:
> 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.

My feeling on this is:  Maybe it would be wise to "just" learn from PyArch 
(and PyBaz) and create something new from scratch.  If there were separate 
bindings for tla and baz then any application supporting tla and baz would 
end up writing an application specific wrapper on top of those two 
wrappers.  I am not sure whether that'd be an ideal solution. 

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

I am very sure that this version string parsing can be done, though.  I 
think the biggest amount of work here would be to install all those 
versions of tla.  It might not look like a nice generic tla version parser 
but I am really sure that it is possible to implement something that works 
and doesn't look too much like a stupid hack.

Speaking about feature-sets.  This is another topic entirely.  I would 
start wrapping the functionality I need and see how it goes.  I would 
define the requirements of my application (like diff this, or tag that).  
Then I'd see how they translate into tla and baz command lines.  Each 
feature would then have at least one backend specific (or dependent on 
backend and backend version) implementation.  If there's something that 
absolutely impossible to do in a sensible manner when using tla but which 
is easily doable with baz, then, in the application, I'd just disable this 
specific feature.

I think, having a "common" wrapper around both tla and baz is a good way to 
approach this.  At least for building nice applications on top of it. 

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

Hmmm.  To be honest, I don't use baz.  And so my focus would be to base the 
wrapper on tla (so tla kind of specifies the feature spectrum) and then 
make baz specific implementations of the supported features.

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

You are 100% right about the being-generic is difficult approach.  My view 
on this is:  Being generic is nice and elegant but being able to deal with 
the real world is often more important.  Dropping in a few very specific 
functions/methods to let the rest of the framework continue to be generic, 
I also consider to be an elegant approach :)

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

As mentioned before:  This won't be the problem.  It might require more 
lines of code than a nice and generic (compared to the code if the tla 
--version output would be consistent accross versions) - but it can 
certainly be done.

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

That's the tricky part indeed!  I fully agree with you.  What I have in 
mind, as I have mentioned above, is:  to wrap arch features.  Designing a 
framework that uses different implementations for accomplishing feature 
requirements dependent on command line tool kind and version, sounds like 
a nice challenge -- and I think that Python itself will be a great help 
here.

>       * You need to work around bugs specific to each version.

I haven't thought about that one before but this can be adressed in a few 
ways.  The thing is:  If I wrote - let's say - a GUI on top of arch which 
works fine and then suddenly there's a bug in tla that makes the GUI 
non-funtional.  Then I don't really think that I am responsible for this 
and tell people to not use that version of tla until the bug is fixed.  I 
can see that you, when writing PyArch and PyBaz, were in a different 
situation and in order to keep the bindings being usable you had to work 
around such bugs.  I don't have your experience in this regard.  Maybe 
I'll think differently in the future.  But at the moment, my suggestions 
would go along the line of the following:

1. Tell everyone it's not your fault.  This might ideally add a little bit 
of hopefully existing pressure to get the bug fixed at its source - and 
after a short while, when the bug is fixed everyone will be happy.

2. Tell everyone it's not your fault.  This might cause people to step back 
to using a previous version which doesn't have that problem.

3. If the bug is simple enough to fix, provide a patch and point people 
complaining about the bug to your patch until the patch has made it into 
the mainline.

4. If the bug doesn't seem to want to go away and it makes sense, throw in 
a workaround in the version-specific implementation of the feature that 
suffers from the bug.


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

For many things, it might be as easy as marking certain features as 
unavailable (--> disabled in the GUI, for example) if they are not 
supported by the "backend".  As for other things:  I think, by focussing 
on features likely to be used by applications (like GUIs) and taking tla 
as the base some of these problems might just disappear.  Of course, 
things like an evolving namespace syntax should not make it necessary to 
alter the design of the framework based on the version of the command line 
tool -- rather some specific implementations.  I agree, this might turn 
into tricky business.  But at the moment, I probably need to learn more 
about baz to fully comprehend your concerns.

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

That's good advice.

> Hopefully I have not discouraged you from the valuable endeavour of
> maintaining a Arch GUI that does not suck. 

Not at all.  Yet :)

> I just meant to share some of 
> the experience I have accumulated working on PyArch and PyBaz.

And this is very much appreciated.  It is invaluable feedback of someone 
who "has done it before" and therefore knows much more about the problems 
and pitfalls we're facing.

Thanks for this
        -Rene

pgpZ4hz4Mv87i.pgp
Description: PGP signature