date:20190619

Re: GDAPS

2019-06-19 Thread Curtis Maloney

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

Re: Redis cache support in core

2019-06-19 Thread Josh Smeaton

Celery explicitly document their integration with Redis though. I don't 
think we want to take over documenting the setup of a 3rd party package in 
Django.

On Thursday, 20 June 2019 11:00:27 UTC+10, Ivan Anishchuk wrote:
>
> How about making one of the third-party packages an optional dependency? 
> Celery, for example, does that: you can just install celery[redis] without 
> having to figure out what other packages you need to enable redis support.
>
> Ivan.
>
> On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton  > wrote:
>
>> There are already several 3rd party packages that implement redis as a 
>> django cache backend, for example https://github.com/niwinz/django-redis
>>
>> We already have a base class for cache backends - and several 
>> implementing it (such as memcache). I don't think there's much benefit 
>> taking on another backend when it's already got very good support as an 
>> external package.
>>
>>
>> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar wrote:
>>>
>>> Hello,
>>>
>>> I would like to work on Redis support in core, and I would like to 
>>> discuss proper solution for that.
>>>
>>> Redis is getting so popular and almost every modern backend stack uses 
>>> it someway, therefore I think that supporting it as a cache backend in core 
>>> would make Django more appealing. A solution I'm proposing is to extract 
>>> base KV backend from current Memcached and extend it for both Memcached and 
>>> Redis, and this won't add many new code to the core. Also we'll have base 
>>> class for KV storage backends.
>>>
>>> Thanks.
>>>
>> -- 
>> 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 django-d...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> 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/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com
>>  
>> 
>> .
>> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/335b087c-801a-452b-a5b3-a9711e4a00b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Redis cache support in core

2019-06-19 Thread 'Ivan Anishchuk' via Django developers (Contributions to Django itself)

How about making one of the third-party packages an optional dependency?
Celery, for example, does that: you can just install celery[redis] without
having to figure out what other packages you need to enable redis support.

Ivan.

On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton  wrote:

> There are already several 3rd party packages that implement redis as a
> django cache backend, for example https://github.com/niwinz/django-redis
>
> We already have a base class for cache backends - and several implementing
> it (such as memcache). I don't think there's much benefit taking on another
> backend when it's already got very good support as an external package.
>
>
> On Tuesday, 18 June 2019 01:14:25 UTC+10, Dulmandakh Sukhbaatar wrote:
>>
>> Hello,
>>
>> I would like to work on Redis support in core, and I would like to
>> discuss proper solution for that.
>>
>> Redis is getting so popular and almost every modern backend stack uses it
>> someway, therefore I think that supporting it as a cache backend in core
>> would make Django more appealing. A solution I'm proposing is to extract
>> base KV backend from current Memcached and extend it for both Memcached and
>> Redis, and this won't add many new code to the core. Also we'll have base
>> class for KV storage backends.
>>
>> Thanks.
>>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/bdb84d20-0489-4ecd-b198-fa5878f5c617%40googlegroups.com
> 
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CADPNjZ6bvs6d9z6pteqsgj_EzfWkbpuW-pxTtYdU7e0vveA%3Dcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GDAPS

2019-06-19 Thread 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?

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

May I ask for your opinions here?

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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
Description: application/pgp-keys

Re: GDAPS

Re: Redis cache support in core

Re: Redis cache support in core

Re: GDAPS

4 matches

Site Navigation

Mail list logo

Footer information