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

84 views
Skip to first unread message

Diptesh Choudhuri

unread,
Feb 7, 2021, 9:16:45 PM2/7/21
to Django developers (Contributions to Django itself)
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

Adam Johnson

unread,
Feb 8, 2021, 4:30:26 AM2/8/21
to django-d...@googlegroups.com
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

--
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.


--
Adam

Tom Forbes

unread,
Feb 8, 2021, 6:07:37 AM2/8/21
to django-d...@googlegroups.com
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 

--

Diptesh Choudhuri

unread,
Feb 8, 2021, 6:43:07 AM2/8/21
to Django developers (Contributions to Django itself)
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
Reply all
Reply to author
Forward
0 new messages