Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le vendredi, juillet 24, 2020 7:01 PM, David Rashty <[email protected]> a écrit : > Nice! And thanks for sharing! I like this idea too. Why did you include "if > settings.DEBUG" by the way? For the sake of the example > 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. I think changing settings at runtime is not well supported by Django but I might be wrong > * 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. Okay but that means that you're going to have to update your code for every package in the world ... Or at least you could let maintainers paste the install code into their own AppConfig and have indject read setup code from there > * 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. Exposing a full-featured CRUD on an unauthenticated API seems pretty insecure by default, and doesn't that take you to the point where you have to remove generated code, which is what the README complains about with cookiecutter ? > * I did not want to create another prod dependency. "indjections" is only > used during development to create boilerplate code. Boilerplate code: exactly why I keep myself away from Java ! -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/AI5NcXJRY0zjC1NZBy0ix2z2vCJbR73KJIkszOyi7YJvZnI1qY2B-0q1mt7ZMZV6hcLuE_a2Lu9EX9ShhEBNMFHKS8zOanDhEluRGsDqWX4%3D%40protonmail.com.
