Monkey patching Django app in another app

Question

We have a third party lib that we use in our Django 1.9 app. We would like to amend that application with some functionality not in the original app (targeting MongoDB). We currently do this via our own fork of the original lib, but would like to make the changes a bit more orthogonal, so that they might be pulled upstream eventually.

We've tried patching during the app config ready() but model imports are handled before this call in django.apps.registry.populate(), and performing it in the \__init__ suffers from apps_ready == False. What is the best part of the lifecycle to perform this?

class MongoConfig(AppConfig):
    def __init__(self, app_name, app_module):
        super(MongoConfig, self).__init__(app_name, app_module)

        for p in patches:
            patch(*p)

def patch(old, new):
    old_module, old_item = split_mod(old)
    new_module, new_item = split_mod(new)

    print('patching {0} with {1}'.format(old, new))

    old_module = import_module(old_module)
    new_module = import_module(new_module)
    setattr(old_module, old_item, getattr(new_module, new_item))

I've implemented patches both in the `__init__.py` of apps and in the `AppConfig.ready` callback. I don't see how someone can give you an answer that's not going to be pure guessing. What will work where depends on details that you're not giving in your question. — Louis, May 09 '16 at 23:58
We are adapting an existing app (django-allauth) to work with MongoDB. This requires changes to models, views and forms that we are trying to keep orthogonal to the original library. What other information would you like? — mwjackson, Jun 01 '16 at 14:27

score 1 · Answer 1 · answered May 10 '16 at 05:01

1

I am really not for monkey patching (except during test cases, even then I believe mock is better).

Why don't you try the simpler option? Create a proxy of the app within your project (it will be called first, due to Python's lookup system) and then simply patch the methods you want, and bypass the ones you don't to the original app.

So if the component is called "FooProject" you would create another app called "FooProject" in your project, in this app's __init__.py:

from originalproject import FooProject as OriginalFoo

class FooProject(OriginalFoo):
    def override_method_here(self, foo):
       return my_own_magic(foo)

answered May 10 '16 at 05:01

Burhan Khalid

169,990
18
245
284

I forgot to mention this possibility when I commented on the question. I've used it to work around a limitation of [`cmsplugin-iframe`](https://github.com/satyrius/cmsplugin-iframe/issues/5). This method would be preferable to monkey patching, but there do exist cases where a) only monkey patching will work or b) monkey patching allows for a *much* simpler solution. I had a case where I would have had to create one proxy per installed app: more than 20 proxies. The OP has not given us the means to know what would work best to solve their specific problem. – Louis May 10 '16 at 11:06
The app we are attempting to modify is rather large (django-allauth). Unless I'm missing something, this approach is not really feasible due to the fact that we need to patch models, forms and views, all with imports to each other that would also need to be updated. – mwjackson Jun 01 '16 at 14:31
@mwjackson what solution did you end up going with because i am dealing with the same issue OP posted about and trying to decide based on best practices. – Gustavo_fringe Apr 30 '19 at 15:41

score 1 · Answer 2 · answered Dec 16 '20 at 20:56

1

I ended up doing this in the wsgi portion of initialization

In wsgi.py

# Monkey Patch a few things
from huey_monitor.apps import HueyMonitorConfig
HueyMonitorConfig.verbose_name = 'Task Monitor'

answered Dec 16 '20 at 20:56

Kevin Parker

16,975
20
76
105

score 0 · Answer 3 · answered May 10 '16 at 04:54

Monkey-patching is a hack, hard to maintain and should be avoided.

The principle is to patch your code before it gets imported, before Django itself is loaded. Depending on what is your entry point you will find the right place to patch your code.

Using Django 1.9 I can think about two entry points:

wsgi.py - while your code is run on a WSGI container
manage.py - while any management command (shell, runserver, migrate) is run

score 0 · Answer 4 · edited May 27 '17 at 15:23

I just had a similar need to monkey patch the django-allauth/django-invitation adapter and stumbled upon the same limitations (apps_ready == False).

So I used partially what @domtes mentioned, editing manage.py and inserting there a method to rewrite partially the adapter I had to modify and thus appending the required behaviour. By the time django loaded django-invitations, the method was already rewritten.

It was a simple, dirty and possibly not recommended search & replace method in which I rewrote the targeted .py file belonging to the library structure.

It suppose to be compatible to future versions, but I admit it is a source of bugs and problems.

Cheers

Monkey patching Django app in another app

4 Answers4