[Bug 3096] New: RFE: improve mass-check so that it can be run from a different directory, and implement module structure to support 'masses' tools

[bu...@bugzilla.spamassassin.org]

http://bugzilla.spamassassin.org/show_bug.cgi?id=3096

           Summary: RFE: improve mass-check so that it can be run from a
                    different directory, and implement module structure to
                    support 'masses' tools
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Tools
        AssignedTo: spamassassin-dev@incubator.apache.org
        ReportedBy: gary@intrepid.com


[Just in case anyone is thinking about re-orging the programs under 
the 'masses' directory, I'm passing these ideas along. If I had more time, I'd 
take a crack it, but can't do so at the moment.]

I want to run mass-check in much the same fashion that Bob Menschel documents 
in http://www.exit0.us/index.php/BobCorpusTestV2. However, I'd prefer it if I 
could keep my corpus, rules directory, user_prefs directory, and results 
directory in a directory other than SA's build directory. This is mostly 
possilbe but there are a few places where mass-check depends upon being
run within the SA hierarchy:

This is okay, because we can invoke mass-check by its full path under the build 
directory:
use lib "$FindBin::Bin/../lib";
and this is okay because we can override it with the -c option:
use lib "$FindBin::Bin/../lib";

but these are problematic:
$spamtest = new Mail::SpamAssassin ({
  'debug'                               => $opt_debug,
  'rules_filename'                      => $opt_c,
  'userprefs_filename'                  
=> "$FindBin::Bin/spamassassin/user_prefs",
  'site_rules_filename'                 
=> "$FindBin::Bin/spamassassin/local.cf",
  'userstate_dir'                       => "$FindBin::Bin/spamassassin",
because they (apparently) don't have any switches that can be used to
override those settings.

In a separate vein, many of the tools in the mass-check directory that 
calculate hit frequencies, scores and such, often obtain their raw data by 
either parsing reports written by other tools, or by for example reading in a 
file produced by parsing the rules defintioons, via a "use" directive. This all 
works but can make writing other tools somewhat more difficult because it is 
necessary to cut and various routines that parse reports, etc, from other 
program source files, and sometimes this parsing is rather specific to a 
particular program's needs and it has to be modified. Better, I think, would be 
to move the various functions for parsing rules, calculating statistics of 
various sorts, and so on, into an easier to understand and to use, module 
structure.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.