Changing the discovery method for management commands

[Diptesh Choudhuri]

As of now, if you need to create a management command, it is necessary to 
create a file *app_name/management/commands/my_command.py, *and then add 
*app_name 
*to *INSTALLED_APPS *in *settings.py. *This prevents non-django packages 
from defining their own management commands, because it explicitly requires 
them to create a django app which just adds a bunch of unnecessary files to 
their source code.

I propose we overhaul the existing management command discovery system so 
that it is easier to write management commands. Also I suggest we keep the 
default discoverer in place so as to maintain backwards compatibility.

All of this will require documentation and I am ready to make a PR for that 
too. Please tell me if the idea is feasible, and I will get to work on it 
ASAP.

Best
Diptesh Choudhuri

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com.

Re: App label with dot

[Tom Forbes]

Yes, a more friendly error message would be far better here! User-facing 
runtime exceptions like unpacking errors are never good.

This should be quite a simple change to make, I’d suggest opening a trac ticket 
first and we can go from there. 

Tom

> On 18 Dec 2020, at 16:38, Federico Capoano  wrote:
> 
> 
> Thanks Tim, would it be useful to have a more user friendly error message?
> 
> Il ven 18 dic 2020, 11:08 Tim Graham  ha scritto:
>> app_label "should be a valid Python identifier." Dots aren't allowed.
>> 
>> https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.label
>> 
>>> On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote:
>>> Defining the app_label of an AppConfig with a dot, like "myproject.subapp" 
>>> is allowed, but raises an exception in the migration framework (too many 
>>> values to unpack).
>>> 
>>> Did anybody notice this?
>>> 
>>> Is it supposed to be allowed or not at all?
>>> 
>>> Best regards
>>> Federico Capoano
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/3cbMviLrSzI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/134214d9-e3c1-4f74-9920-f0a62d4d675bn%40googlegroups.com.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAERYH6XvS3_z-akSZw_xy8FRHbdZoxeOYN3D_fVyRJ%3D7B9zUFA%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/98CF92C9-1E9D-4F56-9D4E-A6F78737002E%40tomforb.es.

Re: App label with dot

[Federico Capoano]

Thanks Tim, would it be useful to have a more user friendly error message?

Il ven 18 dic 2020, 11:08 Tim Graham  ha scritto:

> app_label "should be a valid Python identifier." Dots aren't allowed.
>
>
> https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.label
>
> On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote:
>
>> Defining the app_label of an AppConfig with a dot, like
>> "myproject.subapp" is allowed, but raises an exception in the migration
>> framework (too many values to unpack).
>>
>> Did anybody notice this?
>>
>> Is it supposed to be allowed or not at all?
>>
>> Best regards
>> Federico Capoano
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/3cbMviLrSzI/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/134214d9-e3c1-4f74-9920-f0a62d4d675bn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAERYH6XvS3_z-akSZw_xy8FRHbdZoxeOYN3D_fVyRJ%3D7B9zUFA%40mail.gmail.com.

Re: SynchronousOnlyOperation: bug or misconfiguration?

[Boris Tsimi]

Yes because django are application of web devellopin

Le ven. 18 déc. 2020 à 17:23, Tim Graham  a écrit :

> Hi, this mailing list isn't appropriate for "is it a bug?" questions.
> Please use django-users instead.
>
> On Friday, December 18, 2020 at 11:00:30 AM UTC-5 Federico Capoano wrote:
>
>> I have a celery task which performs queries and network operations.
>>
>> When deployed with celery with gevent concurrency, I occasionally (but
>> not always) get reports of SynchronousOnlyOperation exceptions being raised.
>>
>> I described the problem in detail on StackOverflow: SynchronousOnlyOperation
>> from celery task using gevent execution pool
>> 
>> .
>>
>> I tried debugging the issue and looking for information about similar
>> issues with django+celery+gevent with little luck, but I have started to
>> wonder if the fact that Django is raising this error there is a bug.
>>
>> I see this error is raised if django detects an event loop, should this
>> apply also to when gevent is using the eventloop?
>>
>> Thanks in advance
>> Best regards
>> Federico
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/341402be-2684-42cc-b4ac-77b778952794n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJ%3D1isd9ESADOEW6uc7t_xSpwj_efw9xkfmM7iyWEEALsFAdAA%40mail.gmail.com.

Re: SynchronousOnlyOperation: bug or misconfiguration?

[Tim Graham]

Hi, this mailing list isn't appropriate for "is it a bug?" questions. 
Please use django-users instead.

On Friday, December 18, 2020 at 11:00:30 AM UTC-5 Federico Capoano wrote:

> I have a celery task which performs queries and network operations.
>
> When deployed with celery with gevent concurrency, I occasionally (but not 
> always) get reports of SynchronousOnlyOperation exceptions being raised.
>
> I described the problem in detail on StackOverflow: SynchronousOnlyOperation 
> from celery task using gevent execution pool 
> 
> .
>
> I tried debugging the issue and looking for information about similar 
> issues with django+celery+gevent with little luck, but I have started to 
> wonder if the fact that Django is raising this error there is a bug.
>
> I see this error is raised if django detects an event loop, should this 
> apply also to when gevent is using the eventloop?
>
> Thanks in advance
> Best regards
> Federico
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/341402be-2684-42cc-b4ac-77b778952794n%40googlegroups.com.

Re: App label with dot

[Tim Graham]

app_label "should be a valid Python identifier." Dots aren't allowed.

https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.label

On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote:

> Defining the app_label of an AppConfig with a dot, like "myproject.subapp" 
> is allowed, but raises an exception in the migration framework (too many 
> values to unpack).
>
> Did anybody notice this?
>
> Is it supposed to be allowed or not at all?
>
> Best regards
> Federico Capoano
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/134214d9-e3c1-4f74-9920-f0a62d4d675bn%40googlegroups.com.

SynchronousOnlyOperation: bug or misconfiguration?

[Federico Capoano]

I have a celery task which performs queries and network operations.

When deployed with celery with gevent concurrency, I occasionally (but not 
always) get reports of SynchronousOnlyOperation exceptions being raised.

I described the problem in detail on StackOverflow: SynchronousOnlyOperation 
from celery task using gevent execution pool 

.

I tried debugging the issue and looking for information about similar 
issues with django+celery+gevent with little luck, but I have started to 
wonder if the fact that Django is raising this error there is a bug.

I see this error is raised if django detects an event loop, should this 
apply also to when gevent is using the eventloop?

Thanks in advance
Best regards
Federico

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/75a43f29-2bda-4d36-a891-960734264b9cn%40googlegroups.com.

App label with dot

[Federico Capoano]

Defining the app_label of an AppConfig with a dot, like "myproject.subapp" 
is allowed, but raises an exception in the migration framework (too many 
values to unpack).

Did anybody notice this?

Is it supposed to be allowed or not at all?

Best regards
Federico Capoano

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72c66644-4b3a-4f4e-a27b-8b9b707c8b80n%40googlegroups.com.

Re: Dogfeeding our signing API

[Mariusz Felisiak]

> My way out of this mess would be to move `signing.dumps` & `signing.loads` 
> onto the `Signer` class itself; this way this functionality would become 
> reusable while allowing to switch how signing is performed. My preference 
> would be to call those methods `sign_object` & `unsign_object` which would 
> make it clear that it will have to run some kind of serializer over it. 
> `signing.dumps/loads` could just call those methods then.
>

 It makes a lot of sense, IMO. Deprecating *signing.dumps()/loads() *is 
probably not necessary, we can leave them as shortcuts (you didn't suggest 
it, it's just my observation).

Best,
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b7c22cef-c9f1-46ac-8304-6f63ceaa874cn%40googlegroups.com.