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

[David Allouche]

On Sun, 2005-05-08 at 16:23 +0200, Rene Schallner wrote:
> 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.

That's what I was suggesting.

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

The most important problem here is modelling archive registration in a
way that supports both baz and tla.

Maybe one can get away with always using the baz model and considering
that baz and tla support different sets of attributes to each location.
tla providirg a special, required, "registered name" attribute and not
providing providing any of the hints the baz registration system
supports. A good place to start would probably be a UI mockup.

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

Yes, it just cannot be a single generic algorithm as for baz.

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

My thoughts, exactly.

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

As I mentioned previously, you can probably benefit from a little more
foresight for the support of archive registration and signing.

> 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 :)

That's where the line is hard to draw :)

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

It's not difficult once you have set the right component boundaries. But
it requires insane feature test coverage so you can catch changes in CLI
behaviour. There's a lot knowledge to be reused in the PyArch and PyBaz
test suites.

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

That assumes a functional and reliable release process.

TLA falls short of providing release that actually fix the problems. For
example, I'm not even sure that recent "tla meta-info" supports telling
empty meta-info files from missing ones.

Baz falls short of reliably providing releases that fix existing
problems without additional disruption, and that's by design.

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

Not really an option when the previous release often has other problems
or is missing important features the user wants.

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

See remark about the release process. TLA is notorious for not
integrating contributed patches. That's actually what led to the
creation of Baz in the first place.

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

It's just more user friendly to do it up front. Generally problems can
be worked around in a sane and version-specific way.

But I should stop patronising you now. You'll find out by yourself, and
hopefully future releases of TLA and Baz will be easier to wrap
consistently than the historical ones.

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

Another issue that pops up is the need to have version-specific test
cases.

All in all it's not that big an issue. I did inflate my concerns a bit
to get my message through.

-- 
                                                            -- ddaa

signature.asc
Description: This is a digitally signed message part