Creating plug-in applications: how to enable forks of popular libraries and prevent name conflicts?

I am creating an application that I am trying to keep connected. The only problem is that I need to change django-mailer so that my application can track which emails were sent / not and have access to the contents of the email.

What is the best approach to make sure this doesn't conflict with others using django-mailer or any other python library that I solve for fork / tweak for my own application?

Should I rename the mail program to my fork and all its corresponding import? Am I missing something easier?

+4
source share
1 answer

You can solve this problem with the function. Create a function that performs both functions:

  • Make sure you can get what you want.
  • Make sure the message is sent.

Or you can make even heavier plumbing. Make sure you document it well and try to get other people to not try it at home for every useless purpose; instead, contact the Django or Django-mailer teams and ask them if they can arrange a better solution.

  • decorate the EmailMessage class from the django.core.mail module: make sure that when the message is sent successfully, the information you want is also delivered to another place.

     # wrappedmailer.py from django.core.mail import EmailMessage class WrappedEmailMessage(object): def __init__(self, message): self.__message = message # more initialization # override all EmailMessage methods: # do what you want with what is provided, # then return self.__message.method(...) 
  • Then, when your application is initialized, before downloading django-mailer you can do the following:

      import django.core.mail import newmailer django.core.mail.EmailMessage = newmailer.WrappedEmailMessage 

The django.core.mail module remains in the cache as part of the same Python process, so whenever django.core.mail is imported, the EmailMessage class will actually be the WrappedEmailMessage class.

0
source

All Articles