[pacman-dev] Namcap 2.8 release and future plans
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/ * 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 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 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. 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. -- Rémy.
On Sun, Jan 30, 2011 at 2:40 PM, Rémy Oudompheng <remy@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
participants (2)
-
Dan McGee
-
Rémy Oudompheng