Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Email-Filter CPAN distribution.

Report information
The Basics
Id: 8558
Status: rejected
Priority: 0/
Queue: Email-Filter

People
Owner: Nobody in particular
Requestors: bradb [...] bbnet.ca
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Email::Filter-based scripts need to be easier to test: --dry-run and --verbose
I'd like a way for my Email::Filter scripts to be more testable. I want to be able to see what it's going to do without it actually doing it. So, if I write a script like (I'm new to Email::Filter and this is very untested; apologies if something looks a little bizarre): ## mailfilter ## use Email::Filter; my $filter = Email::Filter->new(emergency => "~/Mail/lost+found"); $filter->accept("~/Mail/perl"); $filter->accept("~/Mail/archives"); ... I'd like to be able to test this something like: $ ./mailfilter --dry-run --verbose ~/Mail/Inbox and see output something like: ACCEPT: From: someone@example.com => ~/Mail/perl ACCEPT: From: someone@example.com => ~/Mail/backup ... and thus, a line output for each action taken with a piece of email. REJECT: From: spammer@example.com REASON: We don't accept spam. IGNORE: From: anon@example.com PIPE: From: python-list@python.org COMMAND: listgate python-list etc.
On Mon Nov 22 10:16:26 2004, guest wrote: Show quoted text
> I'd like a way for my Email::Filter scripts to be more testable. I > want to be able to see what it's going to do without it actually > doing it. So, if I write a script like (I'm new to Email::Filter > and this is very untested; apologies if something looks a little > bizarre):
I agree with the sentiment. The verbosity would be simple enough if you wrote a simple set of hooks. You could write Email::Filter::Logged to hook onto each of its triggers to log that an action would be taken. For now, the "don't really reject/accept/etc" is tougher, as these are not adequately abstracted. Once they are (one ->reject calls ->exit_rejected (or something)) then you could write a subclass that replaces those actions with logging or something else. I think the only request here, for the PEP, is to make that sort of subclassing possible...
With no work done on this in years, I'm marking it rejected under the notion that it's not ever going to get done. Any actual work toward this feature should be supplied as a pull request or github issue. This repo will point to a github repo upon the next release, coming soon. -- rjbs