Re: [Gnu-arch-users] PyArch newbie observations/questions

[David Allouche]

On Sat, May 29, 2004 at 12:40:20AM -0400, Aaron Bentley wrote:
> Good grief.  This has been banging around inside the gnu mail system for 
> 3 days!  Feel free to use reply-all to me.

Are you in such a hurry?

> David Allouche wrote:
> >
> >I think DELTA would rather be a top-level function like:
> >
> >  arch.delta
> >      a: Revision|ArchSourceTree
> >      b: Revision|ArchSourceTree
> >      out: DirName
> >  => Changeset
> 
> Well, it could be
> def delta(self, from=tree_latest_revision(), to=tree_root(), output=None):
> 
> With no arguments or with just "to" specified, it would behave like changes.

I'll drop pedantic mode for a moment, you seem to mean (using my made up
syntax, which avoids the ambiguities and bugs in your prototype):

    arch.ArchSourceTree.delta
        [from: Revision, default: self tree-revision]
        [to: Revision|ArchSourceTree, default: self]
        [output: DirName, default: /tmp/something then remove it]

Let me hit again the nail about the the underspecified "output"
argument. Omitting it only makes sense for CHANGES where there is an
expected default dirname, or if there is a way to get the stdout result
of the command, which your prototype does not provide.

Also putting the file in /tmp will probably annoy people who use /tmp
over NFS. I know that's a stupid thing to do, but from what I can read
here, there are a lot of stupid and weird setups around.

Anyway, I'm not going to implement it or accept it that way. DELTA
must be allowed to operate without a ArchSourceTree being available, so
it must be a module-level funtion, regardless of additional arguments
about symmetric polymorphism or mysticsm that I could come up with.


> >In my understanding, CHANGES is different from DELTA in several
> >ways:
> >
> >   1. CHANGES can save its output changeset under a default name in the
> >      tree-root, named after the master revision.
> 
> True.  I'm not aware of a use for this, though.

What about implementing alternative changeset serialization commands?

CHANGES --DIFFS is tuned to the expectation of kernel hackers and
includes stuff like explicit ids and merged patchlogs which are not
always useful or desirable.

Well, sure, one could use unique race-free names, but since CHANGES
itself cannot run concurently, there is not much point to it... Let's
wait until the current discussion about concurrent runs of CHANGES is
resolved.

> >   2. CHANGES can accept a "limit file set" (oh! that needs to be
> >      supported too) in a way similar to COMMIT.
> 
> AFAIK, the CHANGES limit doesn't work.

Looks like tom is cooking up something...

Bah... the first to try to implement full CHANGES support will have the
honour to try and find out.


> >   3. CHANGES uses the tree-revision by default.
> 
> True, but I don't see that being a big advantage, when we can easily 
> determine the tree revision.  I expect pyaba to pass a revision argument 
> to changes/delta 99% of the time.

Okay about pyaba. Still that's a significant difference of signature
between CHANGES and DELTA.


> >   4. CHANGES is used in different contexts than DELTA, and though it is
> >      essentially based on a subset of the functionality of DELTA, I
> >      consider it as an important "library" operation.
> 
> I think delta could be used in the same places just as conveniently, if 
> it had sensible defaults.

If your sensible defaults involve making delta a method of
ArchSourceTree, I do not consider them sensible.


> >      On the other hand, DELTA _is_ a fundamental operation of the
> >      archive layer (unlike CHANGESET which is a fundamental operation
> >      of the changeset layer) because it is an extension point for
> >      transparent optimizations (pristines cache, revlib, smart server).
> >
> >You are welcome to debunk my arguments, so far I think providing a
> >WorkingTree.changes method would be generally useful and convenient.
> 
> I won't stand in the way of WorkingTree.changes, but I do want to have 
> (and use) delta.

Do you have a problem with arch.delta instead of
arch.ArchSourceTree.delta?

> >>What about the stuff changes dumps to stdout, and the diffs output?
> >
> >The Changeset class should provide all that information in a convenient
> >and efficient way. The diffs output looks like a CLI convenience feature
> >to me, not to be supported explicitely in PyArch.
> 
> The changeset output is nice to have for Pyaba.  To colorize it the 
> right way, we'd need to parse the leading letters.
> 
> >Well, I can imagine the incremental output being useful to provide
> >visual feedback, but it would not really fit the bill (it cannot be used
> >to provide an ETA) and I do not see offhand how to make it fit in the
> >current framework.

Are you talking about the --diffs output or about the incremental output
(where the leading letters are indeed important)?


> >That could be supported using an extended version of
> >arch.util.StringOutput (passed as a keword argument to
> >arch.WorkingTree.changes and arch.delta), but that would need much more
> >reflexion to get it right.
> 
> It seems to me that we'd want a per change iterator.

I was rather thinking about a more general mechanism for methods which
provide incremental output one could want to monitor. For example
library-add and changeset-applying functions.

The per-change iterator makes sense for CHANGES, but it would be the
function-specific layer.


> >I admit I am not sure about that choice. The reason why it was done that
> >way in tla was because relinking requires doing the greatest part of the
> >work of CHANGES, and doing it in one place prevented code duplication.
> >It is a feature of libtla that CHANGES is used to perform relinking..
> 
> My argument pro a relink command is that relinking isn't at all central 
> to the functionality and purpose of changes.  It was convenient to stick 
> it there, but it doesn't really belong there.

Point taken, Tom asked. That's a fuzzy issue and I do not really care
which way it is done. That is probably going to be a separate method,
methinks.


> >It could also raise a TreeLintError if the tree is not commitable, and a
> >"strict" boolean keyword argument to control when to raise such an
> >exception. But that would require multiple tree inventories, and that
> >would be a big performance penalty.
> 
> You could avoid doing tree-lint except when there's a lint failure (exit 
> status 2)

Right.

> >This is a common operation to check only for the _presence_ of any
> >change, it could be implemented more efficiently, since the outcome is
> >known once any change is detected, and it does not required the creation
> >of a changeset on the disk. Currently, that would be implemented using
> >"tla changes" without --keep or --output.
> 
> Sure.  In fact, I'd like a arch.WorkingTree.has_no_changes() function 
> that throws an exception if changes are present.

I think that should rather be a pyaba utility.

> >Frankly, I do not even have a clear idea of what the output of tree-lint
> >looks like in the general case.
> 
> That output actually looks unambiguous to me, since it has two newlines 
> between the end of a file list and the heading of the next list.

Okay... then it looks like it can be done sanely... 

> >>There's also the option of adding an easily&reliably-parsed output 
> >>representation to tree-lint.
> >>Also, I'm a bit confused about how I should be importing pyarch into 
> >>pyaba.  Should I be adding pyarch/arch to my PYTHONPATH?  Sticking it 
> >>into my pyaba directory as a nested tree?
> >
> >
> >That's not a PyArch specific issue.
> 
> Yeah.  Like I said, I'm a grasshopper.  I didn't even know Python lacked 
> destructors 'till today.  I miss RAII already.

There are destructors, they are just different from C++ dtors.

This is the __del__ special method.
http://docs.python.org/ref/customization.html#l2h-174

A lot of RAII is irrelevant to Python because memory handling
(generally) just works. Most of the rest can be successfully implemented
using __del__. For example, file objects which are delete w/o being
closed close the file on __del__. My magic
arch.util.exec_safe_iter_stdout terminates the child process when an
instance is deleted before reaching the end of the output.


> Here's a PyArch-specific issue.  I could ship pyaba with PyArch in a 
> subdirectory.  I'd forward any revisions that affected PyArch to you, of 
> course.

For the time being, I think that's the way to go. We'll iron out
specific issues later.

-- 
                                                            -- ddaa