I think it would be quite simple to add support for setuptools entrypoints into the discovery code (using Poetry, or with equivalent setup.py/setup.cfg statements):
[tool.poetry.plugins.django] “setup_pytest" = “pytest_django.commands.setup_pytest” Despite it being easy I’m not sure there is a compelling enough reason to add this is. Can you elaborate on exactly what `setup_pytest` would do? I see use cases mainly around commands that modify files in your Django project after installation, can you think of any other situations where this would be useful? Tom On 19 Dec 2020 at 13:27:57, Diptesh Choudhuri <diptesh.choudh...@gmail.com> wrote: > As you said, most cases. The remaining cases have absolutely no way of > defining management commands. One example is *pytest-django *which > doesn't provide a django app but could benefit with a mangement command > *python > manage.py setup_pytest*. > > On Saturday, December 19, 2020 at 2:11:32 PM UTC+5:30 Adam Johnson wrote: > >> Why? I don't see an impetus to avoid creating a Django app. In most use >> cases there are related models or other Django bits to go with a management >> command. >> >> On Sat, 19 Dec 2020 at 01:48, Diptesh Choudhuri <diptesh....@gmail.com> >> wrote: >> >>> As of now, if you need to create a management command, it is necessary >>> to create a file *app_name/management/commands/my_command.py, *and then >>> add *app_name *to *INSTALLED_APPS *in *settings.py. *This prevents >>> non-django packages from defining their own management commands, because it >>> explicitly requires them to create a django app which just adds a bunch of >>> unnecessary files to their source code. >>> >>> I propose we overhaul the existing management command discovery system >>> so that it is easier to write management commands. Also I suggest we keep >>> the default discoverer in place so as to maintain backwards compatibility. >>> >>> All of this will require documentation and I am ready to make a PR for >>> that too. Please tell me if the idea is feasible, and I will get to work on >>> it ASAP. >>> >>> Best >>> Diptesh Choudhuri >>> >>> -- >>> 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/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/a7f9bf60-da49-404b-ac70-192220149059n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/8d85fcfa-8d1a-4e03-90e1-a00e07f6b6can%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/8d85fcfa-8d1a-4e03-90e1-a00e07f6b6can%40googlegroups.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/CAFNZOJNfOPV1aHdohxCtruDo0wN%2BFZhF5229CEYsYRk0qB1C_g%40mail.gmail.com.
