Django App plugins

47 views
Skip to first unread message

Christian González

unread,
Jul 26, 2018, 7:27:28 PM7/26/18
to django...@googlegroups.com
Hello,

I'm asking myself since a while how to create a Django app with plugins.
I mean an extensible application that can be extended by plugins from an
"app store". I did a lot of research on that, and it's not easy to
manage it.

I'm doing that using partly the REST framework for an API, and graphene
for primary communication from the (Vue) client to the server, Django
channels for communication from server to client.

The plugins must be able to:

* have own models
* have own code that plunges into existing hooks (already done using a
plugin system)
* have own URLs
* have own Graphene Schema (works using plugin system)
* have own REST serializers (should work using my plugin system)
* etc.

The main problem is that dynamic loading of Django APPS  is not really
possible since Django somewhat 1.7-1.9 with the new loading system. So
everything that stands in settings.py is frozen after Django has started.

Apps that are downloaded after that and inserted into the system, are
"ignored" by Django core.

What I did so far: I made a PluginManager with a middleware that
dynamically searches a plugin directory for "apps", and adds their
Appconfig to django.apps. That does not really work well.

Is there a better possibility? Sure, I can make a custom format for
plugins, but I'd like NOT to reinvent Django's wheel and create
boilerplate code for loading models, migrations, schemas, admin parts,
etc. again when django apps do that already.

Has anyone created an application that dynamically loads code AFTER
Django start, with Django 2.0+?

If you'd like to see some code, have a look at
https://gitlab.com/nerdocs/medux/MedUX/tree/develop (the develop
branch), mostly at medux/extensionsystem/pluginmanager.py

I know all the stackexchange questions about dynamically loading code,
but that all only works for earlier Django versions.

Any help/hints welcome.

--

Dr. Christian González
https://www.nerdocs.at
+43 650 7644477


Christian González

unread,
Jul 29, 2018, 5:03:06 AM7/29/18
to django...@googlegroups.com

anyone?
I wondered if I'm the only one that has such a use case? Create a Django
application with downloadable extensions of the code? How do you do the
models/migrations?

Ravi Kirana

unread,
Jul 29, 2018, 7:44:14 AM7/29/18
to django...@googlegroups.com
Friends
Can I use django from spyder


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ef713713-d716-8ea2-78c2-e21735384cf3%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

Melvyn Sopacua

unread,
Jul 29, 2018, 2:20:11 PM7/29/18
to django...@googlegroups.com
On zondag 29 juli 2018 11:02:30 CEST Christian González wrote:
> anyone?
> I wondered if I'm the only one that has such a use case?

I think so. Why not distribute it as a Django **project** so the plugins are
reusable apps.
You can also nest apps, like "coolstuff.plugins.*". It may get tricky with
unique app labels though.

Anyway, there's plenty of examples of Django based software that is
distributed as a project. Mezzanine is one of them.

There might also be another reason and that is that in the Python community,
there's a good realisation that downloadable and instantly installable plugins
for a web project without dev(ops) interference isn't necessarily a good
thing.
--
Melvyn Sopacua


Christian González

unread,
Jul 29, 2018, 5:15:11 PM7/29/18
to django...@googlegroups.com
On zondag 29 juli 2018 11:02:30 CEST Christian González wrote:
>> anyone? I wondered if I'm the only one that has such a use case?
>
> I think so. Why not distribute it as a Django **project** so the
> plugins are reusable apps.
I think that's the best idea yet. My application will be a -eh- "bigger"
one sometimes.
>
> You can also nest apps, like "coolstuff.plugins.*". It may get tricky
> with unique app labels though.
That's no problem. server side filtering in the app store.

> There might also be another reason and that is that in the Python
> community, there's a good realisation that downloadable and instantly
> installable plugins for a web project without dev(ops) interference
> isn't necessarily a good thing.
Mh, not really. Look at Owncloud/Nextcloud. Is PHP, but a good example
that this works. My plans are similar.
But I'm convinced ATM that squeezing Django itself into a pluggable apps
evolvement isn't the best idea.

I'll go with plugins that are separate entities, although that means
that I have to reimplement migrations and module loading myself. But
everything else is easier then.


Melvyn Sopacua

unread,
Jul 30, 2018, 1:36:23 AM7/30/18
to django...@googlegroups.com
On zondag 29 juli 2018 23:14:34 CEST Christian González wrote:
> On zondag 29 juli 2018 11:02:30 CEST Christian González wrote:

> > There might also be another reason and that is that in the Python
> > community, there's a good realisation that downloadable and instantly
> > installable plugins for a web project without dev(ops) interference
> > isn't necessarily a good thing.
>
> Mh, not really. Look at Owncloud/Nextcloud. Is PHP, but a good example
> that this works.

I have a good amount of experience with Magento, which has the same principle
and dealt with all the downsides of it. But I personally don't know of any
similar project within the Python community.

Doesn't mean it doesn't exist, just not as wide spread and after having dealt
with the security holes, low quality not performing code, layout breakers and
what not - I can't say I'm surprised. Magento has invested quite a bit in ways
to check code quality on everything that hits the store.

Either way, keep in mind that you're not going to solve this *just* at the
Django layer. You'll need some way to trigger the WSGI processor to load the
new code in a safe manner and then run migrations. Good luck!

--
Melvyn Sopacua


mottaz hejaze

unread,
Jul 30, 2018, 8:19:25 AM7/30/18
to django...@googlegroups.com
wow , i faced the [ static and preload problem ] of settings.py once .. you cant govl around it becouse its how they designed django , you cant even pass empty containers for any future values , or will be calculated from the very next script after settings.py , you cant do that , there is no such a lazy load in settings.py so dont try this way , think of another way or you have to mess with django source code ..


one hack around is to load all the plugins once you create the project , but make them hidden or unaccessible untill the user want a certain option-plugin so you make it visible for him 

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

Christian González

unread,
Jul 30, 2018, 9:04:21 AM7/30/18
to django...@googlegroups.com

>
> one hack around is to load all the plugins once you create the project
> , but make them hidden or unaccessible untill the user want a certain
> option-plugin so you make it visible for him

This is not possible, as it should be possible to download and install a
plugin with one click, and it's running. And that's a heck of a task in
Django, OMG.
Right now, I'm overthrowing the "one django app as a plugin" system,a s
it has too many disadvantages.

Reply all
Reply to author
Forward
0 new messages