[pacman-dev] Namcap 2.8 release and future plans

[Dan McGee]

On Sun, Jan 30, 2011 at 2:40 PM, Rémy Oudompheng <remy at archlinux.org> wrote:
> Hello,
>
> I would like to release namcap 2.8 : it contains several new rules, and
> several bug fixes.
> * the git repo : http://projects.archlinux.org/users/remy/namcap.git/
You should push all of this to the main repo since it is official, as
far as I am concerned.
> * the source tarball : http://dev.archlinux.org/~remy/namcap-2.8.tar.gz
> * the package : http://dev.archlinux.org/~remy/namcap-2.8-1-any.pkg.tar.xz
And feel free to push this to the repos (probably [testing] first) and
adopt the package.

>
> A notable addition here is the appearance of a test suite.
> Feel free to make any comments.
>
> I don't think I'll do many fixes on the 2.x branch.
>
> My plans for namcap 3 :
>
> * use Python 3
> * parse split packages : PKGBUILDs are parsed in a "pkginfo" structure,
>  I'd like to parse split packages into a tuple
>    (pkgbase, list of pkginfo's),
>  does this look ok to you ?
> * use a class hierarchy for rules :
>    AbstractRule : defines very basic functions (get_name, get_description)
>    PkgBuildRule, PkgInfoRule, TarballRule : derived classes applying
>      to a PKGBUILD, to only one package in a split PKGBUILD, to a
>      tarball
PkgbuildRule would probably be a bit more fitting for case; I've never
seen anyone call it a PkgBuild before. But that is a nitpick, and this
organization makes a lot more sense than the current method-based
callback thing.

>  this allows putting many rules in a single file and loading them using
>  calls to isinstance() or issubclass() functions.
> * optionally : implement dan's idea of turning rules into callbacks.
>  I have doubts about the benefit of such a transformation, but several
>  of our tarballs are quite big and such an optimisation would be
>  valuable.
This would be the beauty of moving to subclasses- once converted,
extracting the per-item functionality into an instance method could be
done, and then eventually remove the looping from the TarballRule rule
types altogether.

>
> Such a callback would be implemented in the following way : define an
> generator/coroutine that yields files in a tarball (it would be useful
> to read raw tar.xz tarballs, for example by reading the pipe out of an xz
> process).
>
> Then the main loop of namcap iterates over this generator and feeds files
> to all relevant rules (TarballRule calass), which should implement a
> method called e.g. read_file().
>
> The rules should gather information about the tarball in one pass.
>
> Then call some method called post_process? analyze? finalize? for all
> these rules: in this method, the rules use all the gathered information,
> e.g. the output of readelf -d, to compute the result and return it.
Sounds feasible, at least.

-Dan