* 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
Correct. It would be *ideal *if the package's author used AppConfig in the way you suggest. "indjections" goal is to bridge the gap between the package's actual implementation and just getting to work out of the box in a given project (with reasonable defaults). * 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 ? Yes, it does. That's why I have the "INCLUDE_APPS" settings variable. But nonetheless, there is going to be stuff to delete/modify just like Cookiecutter. The difference is that with Cookiecutter, you "inject" like 12 things in one shot and have to delete 6 things and hope you don't break something critical in the process. With indjections, you inject one small thing at a time, make modifications, write tests.... and then move on to the next package. It's kind of like the difference between unit tests and integration tests: 2 different flavors that serve the same goal. As far as being "insecure"; that's true in general, but the djangorestframework installer also injects permissions.IsAuthenticated in settings.py. On Fri, Jul 24, 2020 at 1:11 PM '1337 Shadow Hacker' via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > Le vendredi, juillet 24, 2020 7:01 PM, David Rashty < > david.ras...@pandibay.com> 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 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/AI5NcXJRY0zjC1NZBy0ix2z2vCJbR73KJIkszOyi7YJvZnI1qY2B-0q1mt7ZMZV6hcLuE_a2Lu9EX9ShhEBNMFHKS8zOanDhEluRGsDqWX4%3D%40protonmail.com > <https://groups.google.com/d/msgid/django-developers/AI5NcXJRY0zjC1NZBy0ix2z2vCJbR73KJIkszOyi7YJvZnI1qY2B-0q1mt7ZMZV6hcLuE_a2Lu9EX9ShhEBNMFHKS8zOanDhEluRGsDqWX4%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_3ExyrbZC_Jfza47T7of3TGj1_JDR%3D3o6NqrmHqC3XHFw%40mail.gmail.com.
