For ESPs that have incorporated new owners
in their branding, identify the new owner
in the docs:
- Mailgun -> Sinch Mailgun
- Postmark -> ActiveCampaign Postmark
- SendGrid -> Twilio SendGrid
- SparkPost -> Bird ???
(Bird's rebranding of SparkPost seems to still
be a work in progress at this point. In fact,
Bird's rebranding of itself from MessageBird
seems incomplete.)
There are no current plans to rename ESP
backends, as the new owners seem to be mostly
keeping the original ESP names and domains for
API endpoints, docs, etc.
(Similarly, I'm not updating project keywords.)
* Update docs to (usually) refer to Brevo rather than Sendinblue
* Change SENDINBLUE_API_URL to api.brevo.com
(same API is available on both domains)
* Leave code references (settings, backend name, webhook urls)
unchanged as `sendinblue`, to avoid unnecessary client changes
Switch to pyproject.toml packaging, using hatchling.
- Replace all uses of setup.py with updated equivalent
- BREAKING: Change extra name `amazon_ses` to
`amazon-ses`, to comply with Python packaging
name normalization
- Use hatch custom build hook to freeze version number
in readme (previously custom setup.py code)
- Move separate requirements for dev, docs, tests
into their own requirements.txt files
- Fix AnymailImproperlyInstalled to correctly refer
to package extra name
- Update testing documentation
- Update docs readme rendering to match PyPI
(and avoid setup.py)
- In tox tests, use isolated builds and update pip
- Remove AUTHORS.txt (it just referred to GitHub)
* Split test, integration-test, and release workflows,
simplifying config and logic for each.
* Use environment to separate secrets for release workflow.
* Update test matrix with newer Django and Python versions.
Related changes:
* remove Travis-CI config; stop running tests on Travis
* rename live integration test environment variables
to all start with `ANYMAIL_TEST_` (simplifies tox config)
Minimum supported versions are now Django 2.0, Python 3.5.
This touches a lot of code, to:
* Remove obsolete portability code and workarounds
(six, backports of email parsers, test utils, etc.)
* Use Python 3 syntax (class defs, raise ... from, etc.)
* Correct inheritance for mixin classes
* Fix outdated docs content and links
* Suppress Python 3 "unclosed SSLSocket" ResourceWarnings
that are beyond our control (in integration tests due to boto3,
python-sparkpost)
In docs install examples, show double quotes around
package specifiers that include square brackets, to
prevent them from being interpreted as shell globs.
(Helps with installation on Windows and zsh, e.g.)
Closes#188
(Earlier Anymail releases work fine with Django 2.2, and have been
tested against it; this just makes everything official.)
Prefer Python 3.7 and Django 2.2 for "extra" tests (live integration,
optional packages, Django master).
* Flesh out SendinBlue docs, add a readme mention
* Stop trying to list all the supported ESPs in the project short
description and similar headlines -- it was becoming unwieldy.
* Support `pip install django-anymail[sendinblue]`
and use it in Travis tests (for consistency; SendinBlue
doesn't require any extra packages)
* Remove "pre-1.0" warnings in docs, readme
* Jump trove classifer from pre-alpha all the way up to stable
(arguably this should have been "beta" for the past several months)
* The default (GitHub) readme should point
to the stable docs version, rather than
the latest development version.
* The frozen links in PyPI should use the full
patch version number (X.Y.Z), not just the minor
X.Y version. (Leftover from Djrill's branch-based
version management; Anymail uses tags
for versions, and old way was creating incorrect
frozen doc links for patch releases.)
* **Future breaking change:**
Rename all Anymail backends to just `EmailBackend`,
matching Django's naming convention.
(E.g., switch to "anymail.backends.mailgun.EmailBackend"
rather than "anymail.backends.mailgun.MailgunBackend".)
The old names still work, but will issue a DeprecationWarning
and will be removed in some future release.
(Apologies for this change; the old naming convention was
a holdover from Djrill, and I wanted consistency with
other Django EmailBackends before hitting 1.0.)
Fixes#49.
* Trailing comma after "anymail" (see #40)
* Note order doesn't matter
* Change tuple to list (match examples to
Django 1.9+ project template)
[ci skip]
Allow custom MAILGUN_SENDER_DOMAIN in Anymail
settings. (Replaces need to use global esp_extra.)
Improve docs to cover cases where this is needed.
(esp_extra sender_domain is still supported for
overriding individual messages.)
Fixes#26.
Also includes:
* Change AnymailTestMixin.assertDoesNotWarn
to filter specific warning classes.
* Look specifically for AnymailInsecureWebhookWarning
in WebhookBasicAuthTestsMixin.test_warns_if_no_auth
(because we don't care *in that test case* about
DeprecatedInDjango10 warnings).
* message.template_id to use ESP stored templates
* message.merge_data and merge_global_data
to supply per-recipient/global merge variables
(with or without an ESP stored template)
* When using per-recipient merge_data, tell ESP to use
batch send: individual message per "to" address.
(Mailgun does this automatically; SendGrid requires
using a different "to" field; Mandrill requires
`preserve_recipients=False`; Postmark doesn't
support *this type* of batch sending with merge data.)
* Allow message.from_email=None (must be set after
init) and message.subject=None to suppress those
fields in API calls (for ESPs that allow "From" and
"Subject" in their template definitions).
Mailgun:
* Emulate merge_global_data by copying to
recipient-variables for each recipient.
SendGrid:
* Add delimiters to merge field names via
esp_extra['merge_field_format'] or
ANYMAIL_SENDGRID_MERGE_FIELD_FORMAT setting.
Mandrill:
* Remove Djrill versions of these features;
update migration notes.
Closes#5.
Simplify install to just `pip install django-anymail`.
(Rather than `... django-anymail[mailgun]`
All of the ESPs so far require requests, so just move
that into the base requirements. (Chances are your
Django app already needs requests for some other
reason, anyway.)
Truly unique ESP dependencies (e.g., boto for
AWS-SES) could still use the setup extra features
mechanism.
* Add filename param to attach_inline_image
* Add attach_inline_image_file function
(parallels EmailMessage.attach and attach_file)
* Use `Content-Disposition: inline` to decide
whether an attachment should be handled inline
(whether or not it's an image, and whether or not
it has a Content-ID)
* Stop conflating filename and Content-ID, for
ESPs that allow both. (Solves problem where
Google Inbox was displaying inline images
as attachments when sent through SendGrid.)
