[Spambayes] A most peculair problem with SB 1
robert at imagine.co.uk
Thu Nov 11 02:19:33 CET 2004
> OK then, so what about I change pop3proxy_service.py to (when run with
> "install") look for an existing configuration file and if there isn't one
> create one in the parent directory of the script. This would mean:
> * Binary: in the (eg) \Program Files\SpamBayes directory, so the cache
> directories would be at the same level as the 'bin', 'lib', and 'doc'
> * Source (outside Python): in the root spambayes directory, so the cache
> directories would be at the same level as the 'contrib', 'spambayes',
> 'windows' (etc) directories.
> * Source (inside Python): in the root Python directory, so the cache
> directories would be at the same level as the 'Lib', 'DLLS', 'Scripts' (etc)
Any of these /should/ work: we'll only know by testing :-)
If necessary I'll setup a dedicated sandpit box for this and we can find out
how it handles - I'm nervous of playing too much more with the existing box
since it's actually the domain primary :-)
> The directory that is chosen gets:
> * the bayescustomize.ini file
> * the hammie.db database
> * the spambayes.messageinfo.db database
> * the pop3proxy-ham-cache, pop3proxy-spam-cache, pop3proxy-unknown-cache
> (IIRC, that's all at the moment).
> Alternatively, I could get it to create a (eg) "SpamBayesData" directory in
> the parent directory of the script. It would then be in the places
> described above, but have the three files and three directories inside it.
> That's tidier, although slightly more complicated.
Again; these sound like eminently sane proposals: my concern would be that
whatever directory name is chosen and used makes it blatantly clear to
inexperienced first-time installers from reading the directory name that
"this" is where one looks for the config and databases etc. It took me, as a
relatively experienced user of Windows systems, some time to figure out where
everything was - the subdirectory names aren't always instantly intuitive.
> This is do-able as well. I'll try and create something that does this later
> today. (As an aside: it would be nice in many ways if all the spambayes
> code was converted to use the Python logging module rather than print
> statements (the Outlook plug-in actually has it's own logging system), and
> things like this would be much simpler and easier to change as necessary.
> That's a fair bit of work, though - maybe it'll make it to 1.1, but maybe it
I can sympathise with all of that: Windows logging is a nightmare at the best
of times - each of the commercial application developers seems to think
they've found a new and better way: it can be quite stunning to run a global
search on *.log and find out just how much unread stuff has accumulated on the
system. At least with WMI one has the option to place logs into the core
repository - which most experienced users /do/ know about - and my memory of
the Python logging is that it can use Windows Instrumentation fairly
More information about the Spambayes