Changing the discovery method for management commands

[Diptesh Choudhuri]

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

[Adam Johnson]

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.

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

--

Adam

[Diptesh Choudhuri]

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.

[Tom Forbes]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8d85fcfa-8d1a-4e03-90e1-a00e07f6b6can%40googlegroups.com.

[Florian Apolloner]

Nothing is stopping pytest-django to also ship a django app for those management commands though

[Diptesh Choudhuri]

I initially created a PR on the pytest-django package for this management command https://github.com/pytest-dev/pytest-django/issues/897. But after I dug into the source code, I realized it is impossible to add a management command without creating a django app (and having to add a bunch of unnecessary files to the source code). Hence this proposal. Even though Tom's solution will work just fine, I feel django should provide an alternative (and possibly easier) way to register management commands.

[Adam Johnson]

I also don’t see why you can’t add a pytest app to contain the management command.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJNfOPV1aHdohxCtruDo0wN%2BFZhF5229CEYsYRk0qB1C_g%40mail.gmail.com.

--

Adam

[Florian Apolloner]

On Saturday, December 19, 2020 at 3:16:51 PM UTC+1 diptesh....@gmail.com wrote:

and having to add a bunch of unnecessary files to the source code

A bunch? You can literally get away with one file:

➜  testing git:(dc_message_signing) ✗ tree testabc
testabc
└── management
    └── commands
        └── my_cmd.py

This is a complete (!) django app. While I agree that in theory it would be nice to support some other mechanisms, I do not think it is worth the effort given how easy it is to add a command (one file & two directories)

[Diptesh Choudhuri]

Though its just one file and two directories, the use case is common enough to be used by a lot of packages and I think django should do something to support it officially.

[Ahmad A. Hussein]

What are the remaining use cases here? Is the proposed change absolutely necessary for these use cases?

--

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/d1f62c54-8f9c-46a1-ba57-e5506bca3436n%40googlegroups.com.

[Diptesh Choudhuri]

There are no remaining use cases here. The use case I mentioned applies to lot of packages (and new projects could benefit from this change too).

[Adam Johnson]

The use case I mentioned applies to lot of packages (and new projects could benefit from this change too).

Please bring more evidence than just blind assertion.

Also I think it's a net negative, as it complicates the notion of what a management command is. It's against the Zen of Python (https://www.python.org/dev/peps/pep-0020/) to provide more than one way of doing things, when only one would suffice.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/df7a5f44-2f6b-4a42-bcca-767f32b56c43n%40googlegroups.com.

--

Adam

[Diptesh Choudhuri]

I admit I can't find a lot of use cases for this out there. It is just something I think django could benefit from. Please feel free to close this issue.

[Ken Whitesell]

What extra files do you think are necessary? I just created a project consisting of the management/commands directory and a command file. I then installed the package in a venv, imported the module in my settings.py file and added it to INSTALLED_APPS. Works fine. No other files or directories were needed. (Python 3.8, Django 3.1)