Any maintained fork

[iamareebjamal]

As we have noticed, marrow mailer doesn't work on Python 3.8 and there is no development going on. Is there any maintained fork out there? Or is there any alternative we should be migrating our apps to

[amcgregor]

Interesting approach. Of three open PRs, none are critical (impacting usage), and this codebase has been successfully utilized in production environments uninterrupted since inception, on one platform, delivering 20,000 messages in 90 days with a 96.22% deliverability rate. (Engagement stats: on one day, 1115 sent, 587 read, or 52% engagement. This from the actual last 90 days.)

Admittedly 3.8 shifting things around is troublesome, and I am preparing a patch release to address this. However, on the alternatives front, while Marrow Mailer does support a number of back-ends such as Mailgun, which utilize HTTP APIs to perform mail delivery, the entire process of constructing a MIME message becomes… almost pointless overhead in these scenarios? A MIME message isn't actually what's being sent, a custom HTTP API call is being issued; full fidelity of the data can not be guaranteed. The API call being issued is "cherry picking" the details it can understand from the Message instance.

On the alternatives front, if you're using a delivery service which offers an API, use that API, possibly with a Futures thread pool to background/defer the blocking call. For example, dealing with message attachments. APIs often have very particular ways they wish/need that additional content delivered.

On the gripping hand: submit a PR. Spelunking for alternative complex systems (which if using HTTP APIs… ultimately serves no actual purpose) vs. patching a trivial issue in an existing, understood one, seems to be a bit of an escalation. 😉 Interestingly, I'll be completely eliminating marrow.util (which is deprecated and archived). It's not needed / used, esp. after dropping Python 2.

[iamareebjamal]

I neither complained about the stability of marrow mailer nor about its integration with other APIs. So I am absolutely confused about the response detailing deliverability rate, or HTTP API calls for different backends. I am just using SMTP protocol, and hence nowhere comparing it or demanding integration with other backends like mailgun, which adds to my confusion even more.
And given that marrow mailer is the only blocker for us moving to 3.8, I only raised an issue about its compatibility. About raising a PR, I absolutely would, if marrow.utils wasn't deprecated as mentioned in #87. But thank you for the response and moving the project forward by making it compatible to Python 3.8

I just saw that there was no response from maintainers for about 4 months about the compatibility issue and the last commit was from 7 months ago, and hence raised an issue asking if marrow mailer is indeed in development or is there any maintained fork or alternative

[amcgregor]

I neither complained about the stability of marrow mailer nor about its integration with other APIs.

I point out the integrations, because you do not need Marrow Mailer to make use of those services.

So I am absolutely confused about the response detailing deliverability rate, or HTTP API calls for different backends.

To counter the "unmaintained thus doesn't work" implication of being unmaintained. Another reason a package might not be updated: it's actually working A-OK and doesn't actually require changes. Will admit, though, 3.8 is a bit of a thorn.

I am just using SMTP protocol, and hence nowhere comparing it or demanding integration with other backends like mailgun, which adds to my confusion even more.

I'll simplify. SMTP is an ancient, legacy protocol involving higher levels of maintenance burden and overhead, thus cost. Its use has been progressively fading for 20 years, with virtually every single modern solution utilizing HTTP POST to submit messages. A rich MIME message object representation is pointless (and actually a burden of unnecessary overhead) with these solutions, which are the alternatives asked for.

About raising a PR, I absolutely would, if marrow.util wasn't deprecated…

The problem isn't parse* being imported from the wrong location; it's never used within this package. It should be fairly clear the PR would instead need to simply remove marrow.util. It can be outright deleted. Only component of it that would need to be literally copied across is the dynamic scaling futures thread pool implementation.

(Bunch → trivial "attribute access dictionary" implementation required, load_object is actually marrow.package:load, boolean is a dictionary lookup w/ fallback, all compat just disappears, and that's… that's basically it.)

[iamareebjamal]

The problem isn't parse* being imported from the wrong location; it's never used within this package. It should be fairly clear the PR would instead need to simply remove marrow.util. It can be outright deleted.

It cannot be outright deleted
https://github.com/marrow/mailer/search?q=marrow.util&unscoped_q=marrow.util

There needs to be, if not major, but still some form of migration to Python3 native types. But that too it far from can be outright deleted IMHO