Add SHELL_IMPORTS settings to shell

Hi folks,

I’m working on a new feature for the auto-importing shell. The main goals we have achieved so far are:

  • Building a namespace that maps every name to its model, and using that namespace as the shell namespace.
  • Avoiding collisions by giving precedence to the apps listed first in INSTALLED_APPS.
  • Providing access to models that have name collisions by importing all modules’ models with the label <app_label>_models. For example, if you want to access an overridden model from the auth app, you can still access that model using the auth_models module.

Currently, there is an ongoing discussion about the SHELL_IMPORTS setting. Following the proposal by @DevilsAutumn in this post, the idea is to add this new setting. This would allow advanced users to perform manipulations or preprocess data by overriding the command, and it would simplify customization for beginner users so that they don’t have to subclass the command and override a method.

I would love to hear your feedback about this setting!

3 Likes

Hi,

here at $work we use the shell_plus and configure it via custom SHELL_PLUS_PRE_IMPORTS/SHELL_PLUS_IMPORTS/SHELL_PLUS_POST_IMPORTS in base setting;
and almost every developer customize it in its own local settings.

Configure via custom command will require us to update our projects (and project templates) to configure default import with common imports
and write another custom command to configure locally (one for each project for each developer for each instance, so not so handy).

Another case: we use the form “from xxx.shortcuts import *” (shortcuts for shell management), which I don’t understand how to translate to the dictionary form (yes, star import is bad, but these are careful crafted modules for specific purpose).

In short: we would love to see SHELL_IMPORT support, or anyway we will add support in an our custom command.

1 Like