Nice! And thanks for sharing! I like this idea too. Why did you include
"if settings.DEBUG" by the way?
I still think injecting code explicitly has certain advantages:
* I believe AppConfig approach could be implemented in apps.py by the
package author. If they chose not to write their package's configuration
this way, I assume there is a reason.
* The AppConfig approach is a bit of a black box to most app users. I
wanted the result of the "indject" operation to mirror the package's
installation/quickstart docs almost verbatim.
* The injected code is just a starting point. I expect the developer will
want to lock the injected code and make modifications that suit their needs.
* My package doesn't just address settings. It also has the ability to
handle introspection at the app and model level of a given project. For
example, in the latest version of the djangorestframework installer, I
inject a HyperlinkedModelSerializer corresponding to every model of every
app in a given project. I can't imagine how that could be implemented with
the AppConfig approach.
* I did not want to create another prod dependency. "indjections" is only
used during development to create boilerplate code.
If I didn't understand something about your suggestion, please do let me
know.
Thanks!
On Fri, Jul 24, 2020 at 8:38 AM '1337 Shadow Hacker' via Django developers
(Contributions to Django itself) <django-developers@googlegroups.com> wrote:
> About your package, I wouldn't have gone "injecting code" in settings, but
> rather leverage the entry points packaging feature or at least the
> AppConfig feature.
>
> class DJDTConfig(AppConfig):
> def setup(self, settings):
> if settings.DEBUG:
> settings.MIDDLEWARE.append('debug_toolbar.middleware ...')
>
> That would be really nice !
>
> --
> 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/5jO0367eiVg/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/XPd_982R5IJsyC8RcBopdXqjH8w-MQPOk5lsKSLG7abnoNDbQpZWjmuPEaPxsxHJpyKQIFUWa-oTHPDUmAsQvavugge8Caa9ioTZ18Pomr0%3D%40protonmail.com
> <https://groups.google.com/d/msgid/django-developers/XPd_982R5IJsyC8RcBopdXqjH8w-MQPOk5lsKSLG7abnoNDbQpZWjmuPEaPxsxHJpyKQIFUWa-oTHPDUmAsQvavugge8Caa9ioTZ18Pomr0%3D%40protonmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALGYj_0377uJPedHpVy9CuKqF6q2WEXkLCmtSF-PWBrvhpapTw%40mail.gmail.com.
