Re: GDAPS

[Adam Johnson]

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
https://docs.djangoproject.com/en/dev/internals/contributing/

Thanks,

Adam

On Sat, 15 Jun 2019 at 17:14, Christian González <
christian.gonza...@nerdocs.at> 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 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/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 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/CAMyDDM22xjWB_s5G85PC-YhvXQdXs1_yn8vpYGOziOSF2EHPow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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 
> 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 ;-)

* 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 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-develope

Re: Django 2.2 and the watchman reloader

[Tom Forbes]

Just an update to this: I've made a WIP PR to add watchdog support here:
https://github.com/django/django/pull/11480

I'd like to disable it on Windows and MacOS, and there are some tricky
issues to resolve around how events are triggered (watchdog uses a number
of threads internally, and we need to ensure only the main thread triggers
the file changed notification), but otherwise it seems to be working OK
locally.

On Mon, Feb 25, 2019 at 10:22 PM Tom Forbes  wrote:

> I have a small PR here to remove the “watchman unavailable” message,
> whilst keeping the one that specifies which reloader we are using:
> https://github.com/django/django/pull/11025.
>
>
>
>
> On 21 February 2019 at 20:52:29, Claude Paroz (cla...@2xlibre.net) wrote:
>
> Le jeudi 21 février 2019 21:43:43 UTC+1, Tom Forbes a écrit :
>>
>> Hey Claude,
>> Thanks for your feedback on the feature, I fully agree with you. I think
>> we should remove that warning message about the missing package. I will
>> make a PR to do that.
>>
>
> I'm not completely sure it's a good idea to entirely remove the message.
> Maybe just telling the used reloader would be fine.
>
>
>> Regarding creating another reloader: it should not be that difficult to
>> do at all since we have all the other pieces in place. In theory it's just
>> implementing a class with single generator method.
>>
>> If people agree I would like to use the 'watchdog' package for this
>> rather than the pyinotify library as it would be quicker to implement, a
>> lot nicer to work with and is easier to test.
>>
>
> ++1, watchdog is better maintained, looks like pyinotify is dead. Tell me
> if you need help, even if you seems a lot more knowledgeable than me on the
> subject.
>
> Thanks.
>
> Claude
>
>
>> On Thu, 21 Feb 2019, 19:56 Claude Paroz,  wrote:
>>
>>> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :

 Claude,

 I've tested a Django based application on 2.2b1 without watchman on
 Windows, it does tell you about watchman, but it doesn't fail to run.
 Apparently, it falls back to the old way of reloading.   Is this not the
 behavior on Debian/Ubuntu?

>>>
>>> Yes it is. I would say this is still a slight regression in two ways:
>>>
>>> - no messages told you the reload method was not optimal before. So now
>>> people will try to "fix" their system, more than before.
>>> - for Debian-based systems, you could improve the reloading performance
>>> by installing system or pip packages in 30 seconds. Now you have to spend
>>> 30 minutes to search how watchman can be installed and to compile the
>>> package (+ you have to care yourself for any security issue).
>>>
>>> Claude
>>> --
>>> 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-develop...@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/b059553a-e25e-4d90-beed-bf7e0f797305%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/6de70f64-9bbb-4017-bd10-c85e94ae08d0%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/CAFNZOJMLobYmyXQh2vV93%3DP8OCSmKi29-BM9Z1FPiw-YM7FXkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GDAPS

[Curtis Maloney]

[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 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/d8cc1a37-b8ae-3a0c-021b-92ec6f7e5701%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

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  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 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/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 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/67996E66-F881-467A-970B-24B93D7DCE83%40twosensedesign.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Reports - June 2019

[Mariusz Felisiak]

Week ending June 16, 2019.

Updated MariaDB to 10.2.24 on Jenkins.

*Triaged:*
https://code.djangoproject.com/ticket/30557 - order_by() a parent model 
crash when Meta.ordering contains expressions. (accepted)
https://code.djangoproject.com/ticket/30559 - Django 2.2 | Auto-reload 
doesn't detect changes in new apps. (needsinfo)
https://code.djangoproject.com/ticket/30558 - Autocompletion should be 
disabled in the "Add user" form. (duplicate)
https://code.djangoproject.com/ticket/30560 - Error: Submission rejected as 
potential spam. (invalid)
https://code.djangoproject.com/ticket/30562 - Document MariaDB support for 
GIS spatial lookups. (created)
https://code.djangoproject.com/ticket/30563 - Optimize 
django.forms.widgets.Media.__add__. (accepted)
https://code.djangoproject.com/ticket/30564 - Cannot create custom field 
that returns a queryset AND uses pre_save(). (invalid)
https://code.djangoproject.com/ticket/24386 - Querysets with filters and 
exclusions based on deep relations build invalid queries. (duplicate)
https://code.djangoproject.com/ticket/30569 - Count and Sum annotation 
interfere with each other. (duplicate)

*Reviewed/committed:*
https://github.com/django/django/pull/11451 - Avoided useless query and 
hasher call in ModelBackend.authenticate() when credentials aren't provided.
https://github.com/django/djangoproject.com/pull/914 - Removed Chinese 
How-to from robots.docs.txt.
https://github.com/django/django/pull/11456 - Fixed #30553 -- Clarified the 
default value of disable_existing_loggers.
https://github.com/django/django/pull/11457 - Fixed #30548 -- Improved 
exception when expression contains mixed types.
https://github.com/django/django/pull/11376 - Fixed #30486 -- Fixed the 
default value of Aggregate.distinct and updated example of custom aggregate 
functions.
https://github.com/django/django/pull/11459 - Fixed #27486 -- Fixed Python 
3.7 DeprecationWarning in intword and filesizeformat filters.
https://github.com/django/django/pull/10910 - Fixed #30128 -- Fixed 
handling timedelta timezone in database functions.

*Reviewed:*
https://github.com/django/django/pull/11417 - Fixed #30512 -- Used 
email.headerregistry.parser for parsing emails in sanitize_address().

*Authored*:
https://github.com/django/django/pull/11467 - Fixed 
GISFunctionsTests.test_asgeojson() crash on MariaDB 10.2+.
https://github.com/django/django/pull/11468 - Added missing support for 
PointOnSurface function on MariaDB.
https://github.com/django/django/pull/11469 - Refs #29548 -- Doc'd MariaDB 
support for GIS database functions.

I was off on Friday.

Best regards,
Mariusz

-- 
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/09d25c77-b2d4-4d49-82c9-a7a1fb8051e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.