On Sun, Jan 30, 2011 at 2:40 PM, Rémy Oudompheng <[email protected]> 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
