GDAPS

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

GDAPS

Christian González
Hi all,

sorry, I never managed to introduce myself properly to this mailing
list. Christian Gonzalez, more or less hobby programmer, MD as day job.
I maybe never will add something substantial to Django core itself, but
ATM "scratching my own itch" here:

Just wanted to say that I finished "Alpha state" for GDAPS - my "Generic
Django Apps Plugin System" which is an "enhancement" of Django's app
system, enabling Django to create "pluggable", extendable applications
with ease.

Just have a look at https://pypi.org/project/gdaps/

Thoughts, criticism welcome.

Christian

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d251dbee-bc4f-3325-a7bb-bb9d1f996cb1%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Adam Johnson-2
Hi Christian,

Welcome to the django developers list. I have had a quick look over GDAPS and have some comments and questions back for you:

* Your “homepage” link on PyPI is example.com. The usual thing to do here is link to your source host or docs. Set this as url in your setup.py.
* I see you list pretix as an inspiration - did you see Raphael have a talk at Djangocon Europe in April on this? https://youtu.be/QbitxAEEZjI It may be old news to you though if you’re familiar
* GPL can make your project hard to use, because depending on the lawyers it can be interpreted as having to make the website source code public. In the one dependency audit I went through, GPL and AGPL were disallowed and we had to strip a dependency or two because of this.
* What do you think are the implications for Django core? Is there anything Django could do better to support this and all the other plugin systems you’ve looked at? Also I’m totally sure you can contribute, it’s not scary and there is a lot of information on getting started! See 

Thanks,

Adam

On Sat, 15 Jun 2019 at 17:14, Christian González <[hidden email]> wrote:
Hi all,

sorry, I never managed to introduce myself properly to this mailing
list. Christian Gonzalez, more or less hobby programmer, MD as day job.
I maybe never will add something substantial to Django core itself, but
ATM "scratching my own itch" here:

Just wanted to say that I finished "Alpha state" for GDAPS - my "Generic
Django Apps Plugin System" which is an "enhancement" of Django's app
system, enabling Django to create "pluggable", extendable applications
with ease.

Just have a look at https://pypi.org/project/gdaps/

Thoughts, criticism welcome.

Christian

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d251dbee-bc4f-3325-a7bb-bb9d1f996cb1%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.
--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM22xjWB_s5G85PC-YhvXQdXs1_yn8vpYGOziOSF2EHPow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Christian González
Am 16.06.19 um 10:06 schrieb Adam Johnson:
* Your “homepage” link on PyPI is example.com. The usual thing to do here is link to your source host or docs. Set this as url in your setup.py.
Sure. Forgot this when switching from setup.py to setup.cfg. Corrected, thanks.
* I see you list pretix as an inspiration - did you see Raphael have a talk at Djangocon Europe in April on this? https://youtu.be/QbitxAEEZjI It may be old news to you though if you’re familiar

Didn't know this talk, thanks. But I had an email conversation with him a while ago about that and he was the one who I learned a lot from about how to create GDAPS. Basically my implementation does not differ too much, and I even am considering using his "PretixPluginMeta" inner class in the AppConfig of GDAPS plugins too. I just think about other ways ATM - but I'm pretty sure I'll implement his way - in a more generic style.

It even could be that GDAPS plugins are so similar that Pretix *could* switch it's underlying plugin system to GDAPS without changing very much.

He did a really great job there and I never would be able to do this on my own, without the insights he gave me to Pretix. Same goes for PyUtilib.

* GPL can make your project hard to use, because depending on the lawyers it can be interpreted as having to make the website source code public. In the one dependency audit I went through, GPL and AGPL were disallowed and we had to strip a dependency or two because of this.

Yes, you are right too. This was another too fast shot - I'd like to release my project which is using GDAPS under the GPL/AGPL later. GDAPS is a library, and here the GPL doesn't help much. I need to think about it a bit, a little part of the code is from PyUtilib (which is BSD), and a bit copied from Graphene-Django (which is MIT). So maybe I'll switch to BSD too. Recommendations here for Django libraries, or specially GDAPS?

* What do you think are the implications for Django core? Is there anything Django could do better to support this and all the other plugin systems you’ve looked at? Also I’m totally sure you can contribute, it’s not scary and there is a lot of information on getting started! See 

Yes, I'll have a deeper look at the contributing guidelines.
The most parts where I had to struggle within Django were:

* The settings, to let each module provide it's own setting. There is no standardized way of having settings saved. I borrowed the graphene-django way - which had copied it from DRF ;-)

* Django doesn't allow to easily add apps to the running server when already started. Even adding apps to INSTALLED_APPS after loading Django is impossible, it has to be done within the setup process - I solved that using a Pluginmanager method (find_plugins) which is called after declaring INSTALLED_APPS in settings.ps, and which returns an INSTALLED_APPS compatible array which can be merged into INSTALLED_APPS. This method is certainly not able to call DB commands in that early startup point of time.
So what I initially planned, downloading apps from a connected "app store" for my application, installing it "on the fly" (including makemigrations/migrate paths) and hooking in the plugin into the running process is not possible in Django.

I don't have a big problem here, as installing a plugin ATM in GDAPS is just (for projects without SPA/frontend support):

stop server
pip install fooplugin
./manage.py makemigrations
./manage.py migrate
start server

which is perfectly ok for what I need.

* URL routing was easy to integrate - the only thing which is remaining IMHO is - django does not help to "weigh" the rules. But this is a thing I want to implement in GDAPS - to give plugin apps the possibility to add a "weight" to URL paths so they are "ordered" in a more deterministic way.
I just created a ticket where I described that a bit: https://gitlab.com/nerdocs/gdaps/issues/4

Same could go to the INSTALLED_APPS ordering. A "weight" ordering is not ideal here, I think that a dependency resolution system would be much better here. Here Django could help a bit - Django apps are depending on other apps, declared in setup.py or setup.cfg. If this meta information would be available to Django (or GDAPS), the loading of apps (GDAPS plugins) could be at least done automatically in a way that dependant apps are loaded after their dependencies.

So far... much to do.
I hope earth is going to spin slower soon, so a day gets more than 24h. ;-)

Christian

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aba23fb4-1ab5-4ed1-b4c3-28068d7d50be%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Curtis Maloney-2
[forgive me for typing as I think... but sometimes it's the best way to
think ;) ]

On 6/17/19 5:19 AM, Christian González wrote:

> Am 16.06.19 um 10:06 schrieb Adam Johnson:
>> * What do you think are the implications for Django core? Is there
>> anything Django could do better to support this and all the other
>> plugin systems you’ve looked at? Also I’m totally sure you can
>> contribute, it’s not scary and there is a lot of information on
>> getting started! See
>> https://docs.djangoproject.com/en/dev/internals/contributing/
>
> Yes, I'll have a deeper look at the contributing guidelines.
> The most parts where I had to struggle within Django were:
>
> * The settings, to let each module provide it's own setting. There is no
> standardized way of having settings saved. I borrowed the
> graphene-django way - which had copied it from DRF ;-)

I've given some thought to this over the years, and what I think we've
somehow missed in settings until now is ... Namespaces!

Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict
(DATABASES = {} ) when it comes to plugins having their own declared
settings, we may want to move to something a little more formal.

Any plugin or app ought be able to declare its own settings and their
defaults. And ISTM the "obvious" place to do this is in their AppConfig

Except, that may be too late, since we may want/need the settings before
apps are loaded?

So the alternative is for a plugin to declare in its entry points a
reference to its settings declaration. This way, all 3rd party settings
can be gathered, vetted, and applied before having to scan the
INSTALLED_APPS list.

Now what we'll need is a way to avoid namespace clashes, and a
dev-friendly way to update these settings in settings.py

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Benny
Long time lurker first time poster; could this possibly be addressed with something along the lines of SECRET_KEY? It seems to me that no more of a namespace would be needed than a uniquely identifying hash per app/module. Not so much in settings or app_config as __init__, maybe?

Hi,
Benny

> On Jun 16, 2019, at 7:18 PM, Curtis Maloney <[hidden email]> wrote:
>
> [forgive me for typing as I think... but sometimes it's the best way to think ;) ]
>
>> On 6/17/19 5:19 AM, Christian González wrote:
>>> Am 16.06.19 um 10:06 schrieb Adam Johnson:
>>> * What do you think are the implications for Django core? Is there anything Django could do better to support this and all the other plugin systems you’ve looked at? Also I’m totally sure you can contribute, it’s not scary and there is a lot of information on getting started! See
>>> https://docs.djangoproject.com/en/dev/internals/contributing/
>> Yes, I'll have a deeper look at the contributing guidelines.
>> The most parts where I had to struggle within Django were:
>> * The settings, to let each module provide it's own setting. There is no standardized way of having settings saved. I borrowed the graphene-django way - which had copied it from DRF ;-)
>
> I've given some thought to this over the years, and what I think we've somehow missed in settings until now is ... Namespaces!
>
> Whilst we have namespace-by-prefix (CACHE_*) and namespace-by-dict (DATABASES = {} ) when it comes to plugins having their own declared settings, we may want to move to something a little more formal.
>
> Any plugin or app ought be able to declare its own settings and their defaults. And ISTM the "obvious" place to do this is in their AppConfig
>
> Except, that may be too late, since we may want/need the settings before apps are loaded?
>
> So the alternative is for a plugin to declare in its entry points a reference to its settings declaration. This way, all 3rd party settings can be gathered, vetted, and applied before having to scan the INSTALLED_APPS list.
>
> Now what we'll need is a way to avoid namespace clashes, and a dev-friendly way to update these settings in settings.py
>
> --
> Curtis
>
> --
> You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/67996E66-F881-467A-970B-24B93D7DCE83%40twosensedesign.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Christian González
In reply to this post by Curtis Maloney-2

> I've given some thought to this over the years, and what I think we've
> somehow missed in settings until now is ... Namespaces!

I can second this from my POV, having "evaluated" a few plugin systems now.


> Any plugin or app ought be able to declare its own settings and their
> defaults. And ISTM the "obvious" place to do this is in their AppConfig
>
> Except, that may be too late, since we may want/need the settings
> before apps are loaded?
>
> So the alternative is for a plugin to declare in its entry points a
> reference to its settings declaration. This way, all 3rd party
> settings can be gathered, vetted, and applied before having to scan
> the INSTALLED_APPS list.
I want to separate these things: Yes, AppConfig is too late, as the
settings.py is already scanned, and INSTALLED_APPS are determined.
That's because Django works this way. I don't recommend Django to
completely change its way of loading apps.
In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to
INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via
setuptools entry point, like pretix. I therefore added my Pluginmanager
hook, also like pretix. It just finds the plugins and adds them to
INSTALLED_APPS.
But here it is too late. settings.py continues, and *afterwords* all the
apps are scanned for their settings. you can't override them again in
settings.py after that.

What would IMHO clean this problem, would be moving INSTALLED_APPS
outside of settings.py (maybe in a declarative way: yml, cfg file etc.).
Then Django could scan this list, load apps (or do whatever it needs,
scan metadata, check for compatibility, etc.), load their settings, and
*afterwords* run the main settings.py to eventually override some of the
apps' settings globally. This could even be coded with backwards
compatibility, e.g. if installed_apps.cfg is present, use that (and
disallow INSTALLED_APPS in settings.py),  else fall back to
settings.INSTALLED_APPS.

It wouldn't be necessary to make a setuptools entry point for app/plugin
settings. The entry point I would recommend is a "settings.py" for each
app - automatically namespaced or better, with a NAMESPACE = "fooplugin"
- which would enable having 2 plugins using the same namespace (think of
"sub-plugins" of one bigger plugin).


> Now what we'll need is a way to avoid namespace clashes, and a
> dev-friendly way to update these settings in settings.py
I would definitely *allow* namespace clashes, as explained above. Like
in partial classes. A "Textprinter" plugin could have 3rdparty
sub-plugins, which could use the same namespace (HTMLProviderPlugin,
MarkdownProviderPlugin etc.)

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20bd7071-5149-f5e8-86cb-1497d83fc665%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Curtis Maloney-2
On 6/17/19 5:47 PM, Christian González wrote:

>
>> I've given some thought to this over the years, and what I think we've
>> somehow missed in settings until now is ... Namespaces!
>
> I can second this from my POV, having "evaluated" a few plugin systems now.
>
>
>> Any plugin or app ought be able to declare its own settings and their
>> defaults. And ISTM the "obvious" place to do this is in their AppConfig
>>
>> Except, that may be too late, since we may want/need the settings
>> before apps are loaded?
>>
>> So the alternative is for a plugin to declare in its entry points a
>> reference to its settings declaration. This way, all 3rd party
>> settings can be gathered, vetted, and applied before having to scan
>> the INSTALLED_APPS list.
>
> I want to separate these things: Yes, AppConfig is too late, as the
> settings.py is already scanned, and INSTALLED_APPS are determined.
> That's because Django works this way. I don't recommend Django to
> completely change its way of loading apps.

> In GDAPS there are 2 ways of adding apps/plugins: 1. simply add it to
> INSTALLED_APPS. A GDAPS plugin ins a normal Django app. 2. via
> setuptools entry point, like pretix. I therefore added my Pluginmanager
> hook, also like pretix. It just finds the plugins and adds them to
> INSTALLED_APPS.

> But here it is too late. settings.py continues, and *afterwords* all the
> apps are scanned for their settings. you can't override them again in
> settings.py after that.

I'm a little unclear here.

Is it too late because you want to be able to exclude settings from
packages that are installed but you don't want "active" in the project?

That you only want 3rd party "settings contributing" plugins to be
activated when selected?

In which case, doesn't it make more sense to include a plugins.cfg to be
processed _before_ settings.py to decide?  And if handled well, I expect
only an exclusion list may be required [but an inclusion list would be
safer].

> What would IMHO clean this problem, would be moving INSTALLED_APPS
> outside of settings.py (maybe in a declarative way: yml, cfg file etc.).
> Then Django could scan this list, load apps (or do whatever it needs,
> scan metadata, check for compatibility, etc.), load their settings, and
> *afterwords* run the main settings.py to eventually override some of the
> apps' settings globally. This could even be coded with backwards
> compatibility, e.g. if installed_apps.cfg is present, use that (and
> disallow INSTALLED_APPS in settings.py),  else fall back to
> settings.INSTALLED_APPS.

> It wouldn't be necessary to make a setuptools entry point for app/plugin
> settings. The entry point I would recommend is a "settings.py" for each
> app - automatically namespaced or better, with a NAMESPACE = "fooplugin"
> - which would enable having 2 plugins using the same namespace (think of
> "sub-plugins" of one bigger plugin).

Ah, I think I see now.  You want INSTALLED_APPS to be the definitive
truth of all apps _and_ plugins. So it's not possible to have a plugin
that's not also an app?

Sub-plugins opens up the can of works that is dependency resolution.

>> Now what we'll need is a way to avoid namespace clashes, and a
>> dev-friendly way to update these settings in settings.py
> I would definitely *allow* namespace clashes, as explained above. Like
> in partial classes. A "Textprinter" plugin could have 3rdparty
> sub-plugins, which could use the same namespace (HTMLProviderPlugin,
> MarkdownProviderPlugin etc.)

Yes, I did consider this. I think it's valid that a plugin may override
another plugins defaults.

But in the end, the projects settings.py should be final.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6e74db34-c879-f2d3-89ac-88df9d03804c%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Christian González
But here it is too late. settings.py continues, and *afterwords* all the
apps are scanned for their settings. you can't override them again in
settings.py after that.
I'm a little unclear here.

Is it too late because you want to be able to exclude settings from
packages that are installed but you don't want "active" in the project?

The main problem is that settings are code in Django, and not
declarative. You have to *import* them, you don't parse them.

I did that similar to Pretix (mine isn't finished yet): you have to
differ between "installed" and "active".  Packages which are installed
could have a "switch" (which has to be  a changeable, cached, database
state) where to activate/deactivate it. A deactivated plugin is omitted
when itering over its implementations, and doesn't emit signals.

That's what you really want, I suppose?

I think settings - if they are really just *declarative settings*
(without code) - would be nice to be parsed *before* loading apps. But
Django uses .py files as settings, which is a blessing and a course.
There can be conditionals and code in a settings file, which is cool,
but leads to problems. Just to not get me wrong: I don't suggest to
change Django settings model here - .py files are ok IMHO. But We have
to deal with that somehow.


That you only want 3rd party "settings contributing" plugins to be
activated when selected?

In which case, doesn't it make more sense to include a plugins.cfg to
be processed _before_ settings.py to decide?  And if handled well, I
expect only an exclusion list may be required [but an inclusion list
would be safer].
Definitely. That's the main reason I had liked to implement a
declarative plugin spec file with plugin metadata (and maybe default
settings?) instead of having plugin Metadata in the AppConfig as
subclass - like Raphael did in Pretix. This is a cool and easy approach,
but you *have to* import the plugin for getting the metadata - and
plugin code has already run then. It's too late to decide: No I don't
want that plugin running.

But in the end I decided, that from a security POV, it makes no
difference. If you have a plugin already on your server, it doesn't
matter if you have a settings.cfg or pluginspec.cfg file to parse. You
have to trust the plugin anyway when you run it's main entry point later.

And from that POV, using Python code (= a class) as metadata or
settings, is ok, so most certainly I will implement Pretix' Metadata
system into GDAPS as well, additionally being most compatible with Pretix.

It wouldn't be necessary to make a setuptools entry point for app/plugin
settings. The entry point I would recommend is a "settings.py" for each
app - automatically namespaced or better, with a NAMESPACE = "fooplugin"
- which would enable having 2 plugins using the same namespace (think of
"sub-plugins" of one bigger plugin).
Ah, I think I see now.  You want INSTALLED_APPS to be the definitive
truth of all apps _and_ plugins. So it's not possible to have a plugin
that's not also an app?
That was my intention, yes. Because else I would need another entry
point system, Django apps are fine except to the fact that they are not
pluggable.
That's the perfect combination IMHO: Use Django apps as "reusable" apps
like DRF etc, like a Mixin which fulfills the same purpose in different
contexts, applications etc., and use Django apps that are enhanced as
GDAPS plugins to extend *one* single Django application with plugins
that could be written by others.

That's what Raphael said in his DjangoCon talk.

Sub-plugins opens up the can of works that is dependency resolution.
No, this can is already opened when loading plugins/apps via setuptools
entry points. I called "Sub-plugins" the ones that live under the same
"namespace", if that will be an option.


Now what we'll need is a way to avoid namespace clashes, and a
dev-friendly way to update these settings in settings.py
I would definitely *allow* namespace clashes, as explained above. Like
in partial classes. A "Textprinter" plugin could have 3rdparty
sub-plugins, which could use the same namespace (HTMLProviderPlugin,
MarkdownProviderPlugin etc.)
Yes, I did consider this. I think it's valid that a plugin may
override another plugins defaults.
Definitely, but only, if it declares a (at least weak) dependency on
that other plugin. PluginA could "support" plugins like PluginB and C
*if* they are present, and could then override their defaults. I e.g.
decided to implement a "core" plugin - like QtCreator did - to make live
easier for versioning - plugins relaying on "CorePlugin>=2.3.5" can't be
installed then when CorePlugin is 2.0.0. So Core is like any other plugin.
And so all plugins depend on Core plugin and could override its
defaults. Next problem here is, what if 2 plugins override the default
of a third one. The last in the loading row wins then.

There are MANY things to consider - but I decided to just start off, and
look where the journey brings me.

But in the end, the projects settings.py should be final.
Yes.

Christian

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4203175f-50a2-e9b9-0bd7-c50641dc22c0%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Christian González

I'd like to ask another question concerning plugin apps, and hoping your deeper knowledge about Django internals helps here...

I'm implementing the plugin Metadata for GDAPS plugins ATM, and am a bit concerned wether to implement a construct like the Pretix system or not.

Pretix uses AppConfig classes, and creates a inner PretixPluginMeta classs where it sums up all the information it needs. It's easy then to  walk all apps and filter out the ones that have a PretixPluginsMeta - and get their data out.

class PaypalApp(PluginConfig):
    name = 'pretix_paypal'
    verbose_name = _("PayPal")

    class PretixPluginMeta:
        name = _("PayPal")
        author = _("the pretix team")
        version = '1.0.0'
        visible = True
        restricted = False
        description = _("This plugin allows you to receive payments via PayPal")
        compatibility = "pretix>=2.7.0"

What I need for a good plugin life cycle are methods, callbacks that are called when a plugin is "installed" = run the first time, methods for enabling/disabling etc.

The easiest way would be implementing these methods within the AppConfig subclass.

I asked myself why is there a PluginMeta needed? Can't I add those data attributes directly to AppConfig?

So my question on you all is: Is it a good idea to merge those data deeply with tha AppConfig object? I mean, as a plugin in my sense is more or less the same as an app, it won't matter. But deeply inside, I feel that there is something wrong done. Separate concerns should not me mixed - and I don't know what you want to implement in Django's future into AppConfig. Maybe there could be conflicts.

Another way would be implementing the methods too into the PluginMeta object.

May I ask for your opinions here?

And a second question: The DJango docs say, that it's not recommended to use "default_app_config". But in each and every example, even in the tutorials and the Django boilerplate code of "./manage.py startproject foo" are NO Appconfigs addressed in INSTALLED_APPS. Nobody does this, right?

How "obligate" is this recommendation, when noone uses it? Should this be kept?

Thanks,

Christian

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/78db174f-6e3d-1ca8-b7e4-b5218c4836b1%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GDAPS

Curtis Maloney-2
On 6/20/19 7:12 AM, Christian González wrote:
> What I need for a good plugin life cycle are methods, callbacks that are
> called when a plugin is "installed" = run the first time, methods for
> enabling/disabling etc.
 >

> The easiest way would be implementing these methods within the AppConfig
> subclass.
>
> I asked myself why is there a PluginMeta needed? Can't I add those data
> attributes directly to AppConfig?
>
> So my question on you all is: Is it a good idea to merge those data
> deeply with tha AppConfig object? I mean, as a plugin in my sense is
> more or less the same as an app, it won't matter. But deeply inside, I
> feel that there is something wrong done. Separate concerns should not me
> mixed - and I don't know what you want to implement in Django's future
> into AppConfig. Maybe there could be conflicts.
>
> Another way would be implementing the methods too into the PluginMeta
> object.
>
> May I ask for your opinions here?

I would likely keep this interface isolated from the app config, to
prevent future name clashes.

> And a second question: The DJango docs say, that it's not recommended to
> use "default_app_config". But in each and every example, even in the
> tutorials and the Django boilerplate code of "./manage.py startproject
> foo" are NO Appconfigs addressed in INSTALLED_APPS. Nobody does this, right?
>
> How "obligate" is this recommendation, when noone uses it? Should this
> be kept?

I think it's most likely there as a legacy state, in order to reduce the
burden of upgrading.

I do agree it would be better if we abide by our own recommendations.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2c62e976-0b33-b515-f2af-390a551d1b18%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.