Re: Add a stable and documented setting to add files to the runserver watcher

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi Diptesh

The autoreload_started signal looks like the right approach. I see it's not
documented but Django uses it internally for watching template and
translation changes. I think it would be a good idea to document it. I
don't think using the signal hacky, and it's not really a problem that it
requires an AppConfig - it's pretty hard to do anything in Django without
at least one app. Adding another setting is a less preferable solution -
we're trying hard to avoid settings bloat.

django-extensions' runserver_plus command not working with the
auto_reloaded signal is probably django-extensions' problem. The source
code of runserver_plus looks like it has some copy-paste from an older
version of Django's runserver. I suggest you make a PR there if you want
that to work.

Thanks,

Adam

On Mon, 8 Feb 2021 at 02:16, Diptesh Choudhuri 
wrote:

> I am working on a graphQL project which uses django and ariadne
> . This package supports
> 
> loading your graphQL schema from external **.graphql *files. While
> developing the schema, I continually change these files and have to restart
> my *runserver *every time I do so, since the changes are not watched by
> default. This obviously gets quickly tiring since designing a GraphQL
> schema takes a lot of iterations.
>
> There is a somewhat hacky fix
>  to this (here's
> 
> an implementation that I used in a project), but the problem with it is
> that it does not work at all for extensions like *django_extension's
> runserver *command. Additionally, it requires you to have to start an
> app, since it is defined in the *AppConfig, *something which might be
> inconvenient to some people.
>
> I propose we add a *AUTORELOADER_ADD_FILES *variable to the *settings.py *file
> which should be a Linux glob (eg: *AUTORELOADER_ADD_FILES = **BASE_DIR /
> "**/*.graphql"*).
>
> If approved, I would like to make a PR for the same.
>
> Regards
> 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/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%40googlegroups.com
> 
> .
>


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

Re: Add a stable and documented setting to add files to the runserver watcher

[Tom Forbes]

 Hey Diptesh!
It was always my intention to document and expose the autoreloader signals
to third party applications, that way ariadne can configure watches on the
graphql files it knows about. I think this is preferable to having users
having to configure this directly in their projects. We kept the API as
private initially as I wasn’t sure how stable it was going to be, but there
haven’t been any major changes required so I think it’s time to open it up
and mark it as something packages can build upon, if nobody else disagrees?

Regarding a setting - I’m of two minds about this. It’s a good “escape
hatch” for packages that don’t use this signal yet, but it’s also not
particularly… great. Not sure.

Tom

On 8 Feb 2021 at 02:16:45, Diptesh Choudhuri 
wrote:

> I am working on a graphQL project which uses django and ariadne
> . This package supports
> 
> loading your graphQL schema from external **.graphql *files. While
> developing the schema, I continually change these files and have to restart
> my *runserver *every time I do so, since the changes are not watched by
> default. This obviously gets quickly tiring since designing a GraphQL
> schema takes a lot of iterations.
>
> There is a somewhat hacky fix
>  to this (here's
> 
> an implementation that I used in a project), but the problem with it is
> that it does not work at all for extensions like *django_extension's
> runserver *command. Additionally, it requires you to have to start an
> app, since it is defined in the *AppConfig, *something which might be
> inconvenient to some people.
>
> I propose we add a *AUTORELOADER_ADD_FILES *variable to the *settings.py *file
> which should be a Linux glob (eg: *AUTORELOADER_ADD_FILES = **BASE_DIR /
> "**/*.graphql"*).
>
> If approved, I would like to make a PR for the same.
>
> Regards
> 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/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%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/CAFNZOJMCxT4%2BGTNJqJbzr0_1pPTdtv-urNJqWR%2B%3DcJmQP0nEZw%40mail.gmail.com.

Re: Add a stable and documented setting to add files to the runserver watcher

[Diptesh Choudhuri]

In that case, I think we should at least start by documenting the `
*autoreload_started*` signal. Can I make a PR for the same? I think the 
best place to document this will be 
at https://github.com/django/django/blob/master/docs/ref/signals.txt
On Monday, February 8, 2021 at 4:37:37 PM UTC+5:30 t...@tomforb.es wrote:

> Hey Diptesh!
> It was always my intention to document and expose the autoreloader signals 
> to third party applications, that way ariadne can configure watches on the 
> graphql files it knows about. I think this is preferable to having users 
> having to configure this directly in their projects. We kept the API as 
> private initially as I wasn’t sure how stable it was going to be, but there 
> haven’t been any major changes required so I think it’s time to open it up 
> and mark it as something packages can build upon, if nobody else disagrees?
>
> Regarding a setting - I’m of two minds about this. It’s a good “escape 
> hatch” for packages that don’t use this signal yet, but it’s also not 
> particularly… great. Not sure.
>
> Tom 
>
> On 8 Feb 2021 at 02:16:45, Diptesh Choudhuri  
> wrote:
>
>> I am working on a graphQL project which uses django and ariadne 
>> . This package supports 
>> 
>>  
>> loading your graphQL schema from external **.graphql *files. While 
>> developing the schema, I continually change these files and have to restart 
>> my *runserver *every time I do so, since the changes are not watched by 
>> default. This obviously gets quickly tiring since designing a GraphQL 
>> schema takes a lot of iterations.
>>
>> There is a somewhat hacky fix 
>>  to this (here's 
>>  
>> an implementation that I used in a project), but the problem with it is 
>> that it does not work at all for extensions like *django_extension's 
>> runserver *command. Additionally, it requires you to have to start an 
>> app, since it is defined in the *AppConfig, *something which might be 
>> inconvenient to some people. 
>>
>> I propose we add a *AUTORELOADER_ADD_FILES *variable to the *settings.py 
>> *file which should be a Linux glob (eg: *AUTORELOADER_ADD_FILES = **BASE_DIR 
>> / "**/*.graphql"*).
>>
>> If approved, I would like to make a PR for the same.
>>
>> Regards
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/0164ea90-33a2-4ee5-b6cd-df508b6ab013n%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/c71f72b4-c03c-4336-b0d1-9af801c135cdn%40googlegroups.com.

runserver hangs forever, without log of error in console, in two cases

[Michael Calve]

Hello, this is my first time posting, but I think bolstering django's error 
ouput system could be helpful as last week I spent a good amount of time 
debugging some issues related to django migrations

1. I began implementing DRF with DRF-Api-K 
ey and ran 
into this issue when trying to runserver without having first properly 
migrated DRF-Api-Key migrations to my SQL Server database. I forgot to add 
`rest_framework_api_key` app name to my database router so that django 
would know to migrate that app's migrations. It had been a while since I'd 
been in the db router code, and it was my mistake not to double check here 
first. However, it would be nice if django's runtime checks could have 
caught this and told me that I was implementing an app's code without first 
migrating, thus hanging the server (as opposed to having no console output 
at all), which in the beginning stages of implementing a new library, 
having no console warnings or errors makes things a bit more difficult

2. My app uses SQL Server for a backend (with django-mssql-backend driver) 
and a lot of tables are created by my team manually as opposed to with 
django and django migrations, thus not requiring a primary key or even an 
id field. On top of that, I use `inspectdb` command a ton and it is one of 
my favorite django commands/tools, if not one of my favorites of all time, 
but the problem is that inspectdb didn't add `primary_key=True` to the id 
field in the sql server table, because it wasn't declared in the table 
schema. What's really weird is that I was able to setup django and run ORM 
calls on that model in a python shell to test it before testing the DRF API 
against the new model with runserver, so I didn't think to double back and 
ensure that the id field had primary_key=True in its instantiation. I 
didn't end up figuring out the reason until 30 minutes later when I decided 
to run migrate and an error popped up in the console. It would be awesome 
if this error also popped up with runserver

Had both of these issues not happened in the same day I probably wouldn't 
be bring this to your all's attention, but I think beefing up the migration 
runtime checking and adding some if its checks to runserver as well would 
be amazing!

-- 
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/584c1978-cd39-4a02-8b16-f87251ec9f10n%40googlegroups.com.