email?

[gazza]

Hiya,

I need to send an email notification. Can somebody be so kind to
recommend a package to do this in pylons?

Much appreciated,
Gazza

[gazza]

Seem to be answering my own questions.
There is a email package in python already to handle this.

[Alice Bevan–McGregor]

I'm partially biased (as the author) but TurboMail is much easier to
use and more feature-rich than the built-in mail libraries.

— Alice.

[Yannick Gingras]

On March 1, 2011, Alice Bevan–McGregor wrote:
> I'm partially biased (as the author) but TurboMail is much easier to
> use and more feature-rich than the built-in mail libraries.

Turbomail is probably what you are looking for. It provides a high
level API and it's easy to configure from the same .ini file that you
use for the app, allowing you to use different email delivery
strategies in prod and on your dev box.

It provide non-blocking delivery, which is a real blessing if you want
to send email from controller actions withing delaying the response
while the SMPT handshake is taking place.

--
Yannick Gingras
http://ygingras.net

[Blaise Laflamme]

pyramid_mailer is working great too,

http://docs.pylonsproject.org/thirdparty/pyramid_mailer/dev/

[Alice Bevan–McGregor]

> pyramid_mailer is working great too…

TurboMail has the advantage on being completely consistent across
platforms (e.g. a shell Python script, web framework, etc.) and it has
no external dependancies whatsoever. (Testing uses pymta as a local
fake SMTP server.) It also has a much more comprehensive Message class
and more flexible handling of addresses (strings, name/addr tuples,
lists of either) using some descriptor magic.

— Alice.

[oO]

is there a framework adapter for pyramid in TurboMail yet? or can you
just use the pylons one?

One of the nice things about pyramid_mailer is the fact that you stick
your settings in the ini file, and you have a simple
Mailer.from_settings(settings) call.

oO

[Chris McDonough]

On Tue, 2011-03-01 at 17:58 -0800, oO wrote:
> is there a framework adapter for pyramid in TurboMail yet? or can you
> just use the pylons one?
>
> One of the nice things about pyramid_mailer is the fact that you stick
> your settings in the ini file, and you have a simple
> Mailer.from_settings(settings) call.

Not really related to which mailer is used, but if this little stanza
was added to pyramid_mailer's __init__.py (verbatim):

def includeme(config):
settings = config.settings
prefix = settings.get('pyramid_mailer.prefix', 'mail.')
settings['pyramid_mailer'] = Mailer.from_settings(settings,
prefix)

Then during configuration, rather than needing to do imports of
``pyramid_mailer`` and subseqently placing the mailer somewhere where
you can get to it later:

mailer = pyramid_mailer.mailer_from_settings(config.settings)
config.settings['pyramid_mailer'] = mailer

You'd be able to do this during normal configuration:

config.include('pyramid_mailer')

And subsequently in your view code (in either case):

request.settings['pyramid_mailer'].send(mymessage)

- C

[Alice Bevan–McGregor]

On 2011-03-01 17:58:37 -0800, oO said:

> is there a framework adapter for pyramid in TurboMail yet? or can you
> just use the pylons one?

The Pylons adapter is broken in the current release (due to changes
present in the release of Pylons 1.0) and adapters, in general, will be
phased out in the next major version of TurboMail. There are too many
frameworks to warrant the additional code to the general package;
adapters belong in a separate small package or in the framework itself.
The next major release will also be accompanied by a name change to
distance the package from TurboGears. (There is nothing
TurboGears-specific or -required by the TurboMail package.)

Also, the Pylons adapter would simply not be compatible with Pyramid.

> One of the nice things about pyramid_mailer is the fact that you stick
> your settings in the ini file, and you have a simple
> Mailer.from_settings(settings) call.

I'm not sure how much adaption would be necessary, however, utilizing
TurboMail is very similar to the process you describe:

from turbomail.control import interface
interface.start(settings)

However, if the values from the configuration are loaded without
typecasting (integers to integers, etc.) than you might need to model
your adapter after the Pylons one:

https://bitbucket.org/gothalice/turbomail/src/d6331182b0a6/turbomail/adapters/tm_pylons.py

The

atexit code is a nicety for gracefully shutting down the thread pool
while allowing the message queue to drain before actually exiting the
application.

— Alice.

[Christoph Zwerschke]

Am 02.03.2011 03:37, schrieb Alice Bevan�McGregor:
> The next major release will also be accompanied by a name change to
> distance the package from TurboGears. (There is nothing
> TurboGears-specific or -required by the TurboMail package.)

But I hope the TG adapters will not be removed. I'm using it in several
TG1 and TG2 apps and it is working quite well for me.

-- Christoph

[Alice Bevan–McGregor]

On 2011-03-02 03:37:28 -0800, Christoph Zwerschke said:

> Am 02.03.2011 03:37, schrieb Alice Bevan–McGregor:
>> The next major release will also be accompanied by a name change to
>> distance the package from TurboGears. (There is nothing
>> TurboGears-specific or -required by the TurboMail package.)
>
> But I hope the TG adapters will not be removed. I'm using it in several
> TG1 and TG2 apps and it is working quite well for me.

TurboMail won't be going away; the current 3.x branch will exist for some time.

If your package depends on TurboMail, it'll install fine. Upgrading
TurboMail is also a no-sweat operation due to the name change for the
backwards-incompatible API update.

— Alice.

[Daniel Holth]

I'm not using pyramid_mailer (yet?) but I love the underlying Lamson library used to wrap Python's mail libraries. I just keep a lamson.server.Relay() around to send mail through the local mail server (no threadpool). Lamson is also a pretty cool way to receive e-mail.

[Alice Bevan–McGregor]

While I can't really comment on the quality of Lamson (it certainly
seems from the website like it contains many useful features), I could
find no trace of a OOP Message class for the construction of MIME
messages. Things like lamson.server.Relay().deliver() accept raw MIME
messages, with secondary methods (send/reply) to construct /extremely/
limited messages for you.

Threading (or multi-process) is also vital for delivery of mail in
response to user actions. You don't want your controller/view to wait
for an entire SMTP negotiation and delivery session, and repeatedly
opening and closing connections is terribly wasteful. (And can make
the difference between one customized message every two seconds to 150
customized messages per second, which was what I last clocked TurboMail
at before MobileMe blacklisted my testing server. ;)

TurboMail does, in fact, make use of Python's built-in libraries to do
all of its work. The Message class simply takes all of the hassle of
managing Header, MIMEBase, MIMEImage, MIMEMultipart, MIMEText,
encode_base64, formatdate, make_msgid, and e-mail address formatting
out of the picture for developers utilizing it. You can have immediate
(non-threaded) delivery using the immediate "manager", threading using
the "ondemand" manager (with automatic load-based scaling of the worker
thread pool), and it would be fairly trivial to add local sendmail or
other non-SMTP transports.

— Alice.

[Chris McDonough]

On Wed, 2011-03-02 at 16:00 -0800, Alice Bevan–McGregor wrote:
> On 2011-03-02 13:04:16 -0800, Daniel Holth said:
>
> > I'm not using pyramid_mailer (yet?) but I love the underlying Lamson
> > library used to wrap Python's mail libraries. I just keep a
> > lamson.server.Relay() around to send mail through the local mail server
> > (no threadpool). Lamson is also a pretty cool way to receive e-mail.
>
> While I can't really comment on the quality of Lamson (it certainly
> seems from the website like it contains many useful features), I could
> find no trace of a OOP Message class for the construction of MIME
> messages. Things like lamson.server.Relay().deliver() accept raw MIME
> messages, with secondary methods (send/reply) to construct /extremely/
> limited messages for you.
>
> Threading (or multi-process) is also vital for delivery of mail in
> response to user actions. You don't want your controller/view to wait
> for an entire SMTP negotiation and delivery session, and repeatedly
> opening and closing connections is terribly wasteful. (And can make
> the difference between one customized message every two seconds to 150
> customized messages per second, which was what I last clocked TurboMail
> at before MobileMe blacklisted my testing server. ;)

FTR, I don't much care what folks use (I hesitate to even post this,
because the amount I care about this is so little). But it bears
mentioning that pyramid_mailer is not just something that delivers mail
immediately via SMTP.

pyramid_mailer (or actually repoze.sendmail, on which it's based) has
QueuedMailDelivery and the "qp" console script, e.g. the settings are
defined in the config file:

[app:myapp]
# other settings
mail.queue_path = /queue/path

The config file settings are used to create a mailer in the application:

mailer = pyramid_mailer.mailer_factory_from_settings(settings)

Then the mailer is used in views:

mailer.send_to_queue(message) # puts message into queue without delay

(Note that even in this mode, the message won't actually be placed into
the queue until the current transaction (as defined by the "transaction"
module, usually bounded by the repoze.tm2 middleware or pyramid_tm) is
committed.)

The queue is eventually drained by repeated invocations of the "qp"
script that is installed when pyramid_mailer is installed:

$ qp [--options] /queue/path

- C