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

[Aaron Bentley]

David Allouche wrote:
> Yeah! Feedback on PyArch :-)

Here's more :-)

> > Are there mappings to changes/what-changed? (If nothing else, I'm
> > frequently going to want to know if a working tree has uncommitted
> > changes; I may or may not care what they are).
>
>
> No there are not. Patches welcome.
>
> That should be a method in WorkingTree, something like:
>
> def changes(self, link=False, output=None)

I'd rather see delta as a command than changes, since changes can 
(mostly) be implemented in terms of delta.

Presumably, it can take a DirName or a revision type for either parameter.

> If output is set, it should be a string, and the changeset will be saved
> under this name. On normal termination, the method returns a Changeset
> object whose string value (remember, changesets are DirName objects, so
> they are string objects) is equal to output.

What about the stuff changes dumps to stdout, and the diffs output?

> It might make sense to special-case output=True and use the filesystem
> name given by tla when the option --keep is given without --output
> option. That's an option if the changeset name is predictible in a
> race-free way.
>
> Obviously, the "link" option enable source tree relinking with the
> revision library.

Yeah, although that's logically distinct functionality, so it wouldn't 
be terrible to provide a different function for it.  There was 
considerable wailing and gnashing of teeth when I made it an option to 
"changes" in the first place.

> > How about tree-lint? Parsing the output may not be a trivial feature to 
> > add, but even an output status indicating errors/warnings/clean output
> > could be useful.
>
>
> tree-lint is a big problem...
>
> Without any option, the output is difficult to parse and is prone to
> changes, so that's not really reliable.

There's also the option of adding an easily&reliably-parsed output 
representation to tree-lint.  We could ape "inventory"'s leading-letters 
scheme, or produce a directory:

lint-output/untagged-source/foo.c
lint-output/unsourced-tag/.arch-inventory/bar.c.id
lint-output/naming-violation/.lala
etc...

That could be factored out into the
> RevisionIterable, VersionIterable, BranchIterable, and CategoryIterable
> mixins.

I don't understand why these are inherited from each other, since all 
they do is redefine inherited functions to throw exceptions.  But I'm 
just a grasshopper when it comes to Python.

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?

Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.