Auto-installation of 3rd party packges

[Dave R]

Hello all,
I recently got done with v1 of this project:
https://github.com/pandichef/indjections

It's an installation utility for 3rd party Django packages.

But then I started thinking about the issue more generally...

I'm writing here because I'm kind of amazed why Django package installation often requires so many steps e.g., various configurations in settings.py,  some kind URL support in urls.py, add some stuff to base.html.  See django-hijackand django-allauth as examples.

It's all reminiscent of Python package distribution before distutils.

I think some kind of automated way to install packages should be part of the Django itself.  Just a thought...

My solution is to insert bits of code in the "right" places.   I'm curious how others have solved this problem.

Thanks,

Dave

[Kacper Szmigiel]

Hey!

Back in the day, like 2017 or something, I was using Ansible tool for such things. As far as I know (unfortunately I don't work on Django projects on daily basis today) now it's pretty standard to set up a project once, and later just use Docker for a unified dev environment.

I've starred your project, I keep my fingers crossed for its success and development.

Best wishes,
Kacper Szmigiel

--
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/7c10b710-7abf-42e6-b41d-3e856aad288an%40googlegroups.com.

[Dave R]

Thanks Kacper!

The Github README.md should be complete and up to date now.  I hope this project gets some traction.  I put a lot of time into it and could use help writing installation files for the most common 3rd party Django packages e.g., django-allauth, django-filter, etc.

If anyone here thinks my approach is misguided for any reason, I'm definitely interested in hearing about that perspective as well.

Thanks all!

Dave

[1337 Shadow Hacker]

There is https://gitlab.com/nerdocs/gdaps

There has been discussion about this in the past about app auto-configuration (a feature CakePHP has): https://groups.google.com/g/django-developers/c/Lr4br0OzMQE/m/41hP7kaTAQAJ

[1337 Shadow Hacker]

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 !

[David Rashty]

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!

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

[1337 Shadow Hacker]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Le vendredi, juillet 24, 2020 7:01 PM, David Rashty <david....@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 !

[David Rashty]

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

--

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/AI5NcXJRY0zjC1NZBy0ix2z2vCJbR73KJIkszOyi7YJvZnI1qY2B-0q1mt7ZMZV6hcLuE_a2Lu9EX9ShhEBNMFHKS8zOanDhEluRGsDqWX4%3D%40protonmail.com.