[GSOC] feat: auto-importing django shell

[salvo-polizzi]

Branch description

This would be an update of the existing Django shell that auto-imports models for you from your app/project. Also, the goal would be to allow the user to subclass this shell to customize its behavior and import extra things.

• Forum discussion
• GSOC proposal

TODO

• Auto-import all models from the current project/app.
• Test subclassing the shell command and override a method.
• Test importing extra-things (modules, classes, etc.).
• Write a tutorial and document the new features.

Checklist

• This PR targets the main branch.
• The commit message is written in past tense, mentions the ticket number, and ends with a period.
• I have checked the "Has patch" ticket flag in the Trac system.
• I have added or updated relevant tests.
• I have added or updated relevant docs, including release notes if applicable.
• I have attached screenshots in both light and dark modes for any UI changes.

[adamchainz]

Following up from my post on the forum :) You got this !

[salvo-polizzi]

Thank you so much, @adamchainz, for the feedback. Currently, I'm concentrating on writing tests for these features. Do you have any references or suggestions on where to start? I'm considering creating new functions within the shellCommandTestCase to test the auto-imports.

[adamchainz]

Yes, the tests should be within ShellCommandTestCase.

You can unit-test get_namespace() by calling it (imports = Command().get_namespace()) and making assertions on its contents. Then you can write integration tests similar to the existing ones that use command and captured_stdin to test those pathways.

It seems the existing tests don't actually cover launching the various shells. I think it’s worth trying adding coverage, at least for the default python shell, though there’s a risk that calling the startup file, interactive hook, or readline are not a good idea during a test run.

[adamchainz]

Great work getting some tests written! 💪

[adamchainz]

Thanks for your continued iteration. I hope you learn some things from my comments here.

[adamchainz]

No reversed() so that earlier apps take precedence. Test precedence.

[salvo-polizzi]

Hi @adamchainz, I'm sorry to bother you with this question, but I have a doubt about testing the precedence for get_namespace. When you say earlier apps take precedence, do you mean that if we have a name collision, we have to import the models listed first in INSTALLED_APPS?

[adamchainz]

Yes, in a collision the earlier model should be the one in the namespace. This follows the precedence order of other name resolutions in Django, such as for management commands.

As for second, replaced models, it would be nice to provide some way of still providing access, such as by having each app’s models module imported as <app_label>_models, so one could do e.g. auth_models.User. But let’s have a forum discussion about that first, since there are many different strategies we could copy from django-extensions.

[salvo-polizzi]

No reversed() so that earlier apps take precedence. Test precedence.

Hi @adamchainz,

Thank you for your advice. I'll be raising a discussion in the forum the next few days on what strategy to adopt for name collisions.

Apart from that, I've tested precedence with specific tests locally, and I've observed that if we loop over apps_models, we aren't actually giving precedence to the earlier apps because the latest would override the earlier ones. Instead, testing the precedence using reversed() seems to respect the precedence of the earlier apps, which would override the latest listed in the list.

Please let me know if I am saying something incorrect.

[salvo-polizzi]

Thanks @adamchainz again for your reviews. I left some questions in the comments

[DevilsAutumn]

Hi @salvo-polizzi , Thankyou for your constants efforts on this! And special thanks to Adam for reviewing. This PR looks in a great shape already. 🥇
I finally have some time to push this further.