[Gnu-arch-users] PyArch status update

[David Allouche]

Since PyArch was recently mentioned on this mailing-list, I remembered
to merge some pending changes and make a public status update.


Pyarch Code
===========

Johannes Berg has implemented a native NameParser which dramatically
improves performance compared to using "tla parse-package-name" and "tla
valid-package-name" for usage patterns involving a lot of archive
traversals.

He also implemented a support for traversing the output of "tla merges"
with nested iterators.

I have mostly rewritten the new NameParser to make it faster and more
elegant. I have also made the code PyChecker clean, that helped fix a
lot of dormant bugs and ugliness.

Johannes implementation of "merge" inspection is useful for depth-first
traversal but buggy for breadth-first traversal. I have a more correct
and more generic implementation in the works, but I want to be able to
test it with the test suite before releasing it[1].

To that end, test suite (initially contributed by Ben Burns) was heavily
modified to make it cleaner and more correct. I have started adding
features and test cases to create WorkingTree (arch sandboxes) so I
could eventually implement test cases for Version.iter_merges().

    [1] if there is a public demand for this code, I could put it in a
        micro-branch in the meantime.


Help Wanted
===========

Since the test suite is still quite small, it will be a lot of work
before I can validate my new Version.iter_merges() implementation.
Contributions to help it get there are greatly appreciated: test cases
are needed for "commit", "tag" and "star-merge".

Complete test cases and extra functionality needed for the test cases
(the commit support is still _very_ basic) are preferred.


Development Process
===================

There have been a sudden spur of interest for PyArch when Johannes
started working on its graph tool (in his pyarch-contrib branch). To
preserve a clean star-topology I have decided to set-up pyarch--devo
branch in my archive to serve as star-trunk. It will get contributed
patches and changes with little latency and little scrutiny.

address@hidden/pyarch--devo--0.5
    Development branch.

    Get contributed changes quickly with little scrutiny.
    Intended as a community trunk version, caveat emptor, so developers
    will be able to share new patches while preserving a clean star
    topology even when I have little time to spare on PyArch.

address@hidden/pyarch--ddaa--0.5
    My personal development branch

    The merging policy with devo is not clearly defined yet, but the
    focus of this branch is maintaining high quality standards more than
    getting the latest feature.

In order to maintain a high code quality, all contribution to devo
should be PyChecker-clean (use the ./check.py script for that) and come
with test cases (in the ./testarch.py script), if only I had used
Pychecker before... (sight)

-- 
                                                            -- ddaa