Wishlist: have "manage.py shell" execute custom commands on startup

[olau@…]

The first thing I do when I start a shell with manage.py is typing "from blabla.models import *". It's somewhat cumbersome. It would be really cool if I could place a file next to manage.py with this and similar commands and have them pre-executed.

[Jacob]

You can already do this: you can use ​PYTHONSTARTUP or, if you use IPython, a custom IPython profile file.

[Ole Laursen <olau@…>]

Have you tried PYTHONSTARTUP? Does it work for you? It doesn't work for me:

olau@beta:~/myproject$ cat foo.py
from main.models import *
olau@beta:~/myproject$ PYTHONSTARTUP=foo.py python manage.py shell
Python 2.4.4 (#2, Jan  3 2008, 13:36:28) 
[GCC 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> UserProfile
Traceback (most recent call last):
  File "<console>", line 1, in ?
NameError: name 'UserProfile' is not defined
>>> from main.models import *
>>> UserProfile
<class 'main.models.UserProfile'>
>>>

[Ole Laursen <olau@…>]

Hm, I looked into the code and tried following the steps it does to load PYTHONSTARTUP:

olau@beta:~/myproject$ PYTHONSTARTUP=foo.py python manage.py shell
Python 2.4.4 (#2, Jan  3 2008, 13:36:28) 
[GCC 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import os
>>> os.environ.get("PYTHONSTARTUP")
'foo.py'
>>> s = os.environ.get("PYTHONSTARTUP")
>>> os.path.isfile(s)
True
>>> execfile(s)
>>> UserProfile
<class 'main.models.UserProfile'>

As you can see, this works. The problem must be in the way that the shell command sets up things, it is not working for this purpose. I'm going to reopen the bug.

[Eduardo de Oliveira Padoan]

This seems a job for IPython's profile feature. But how to load a specific ipython profile on ./manage.py shell? For example, one could have different profiles for different projects, and completely different profiles for non-Django projects. There could be a way to pass IPython options to the shell command, so we could do ./manage.py shell -p profileformyproject.

[Ole Laursen <olau@…>]

I'm not using ipython and I think it's useful beyond ipython. I think that typically, the commands would be specific for the project. It doesn't sound terribly complicated. Maybe it's merely a question of fixing PYTHONSTARTUP.

[Eduardo de Oliveira Padoan]

If you aren't using IPython, you are losing out!

I have attached a patch that adds a '--profile' option to the shell command. I'm already using it to load my profile.

Usage:
./manage.py shell --profile=foo

You should have a ipy_profile_foo.py on your ~/.ipython/ directory. There are some examples there.

[Eduardo de Oliveira Padoan]

Also, see the shell_plus command extension:
​http://code.google.com/p/django-command-extensions/source/browse/trunk/django_extensions/management/commands/shell_plus.py?r=135

[djsun]

The principles of least surprise and "offer reasonable defaults so new users can get up and running quickly" would suggest that ./manage.py shell should autoload your app models.

Do these principles conflict with the philosophy of Django? If so, I suppose I'm looking at an uphill battle in using the framework.

If these principles do have persuasive power here, I don't see why we should ask new users to jump through any more hoops than necessary to make the "shell" command be useful out of the box. (If you want power users to have customizability, then great, let that be an option too.)

[Russell Keith-Magee]

This was closed by Jacob, and I don't see any compelling reason to reopen it.

Python requires that you import code that you require. It's not "jumping through hoops" or "conflicting with the philosophy of Django" to expect users to write Python code when presented with a a Python prompt. The Principle of Least Surprise says that you should do the least surprising thing - to me, this means that starting a Python shell should provide you with a clean python environment, not one that has been magically populated with some subset of all possible imports.

If you don't like this decision, there are at least two workarounds mentioned in this thread.

[Ole Laursen]

shell_plus seems to do what I want. russelm: note that the bug was closed on the grounds that PYTHONSTARTUP worked for this purpose which does not seem to be the case. But I'll contact the shell_plus author and ask whether there's interest in supplying a patch, it seems generally useful. It could be "python manage.py shell --autoload" or something like that.

[hekevintran@…]

Hi Russell, I have a very compelling reason to reopen this ticket: the change that was supposed to support PYTHONSTARTUP does not work. Here's the proof it doesn't work:

# start.py
import datetime

$ export PYTHONSTARTUP=/Users/haitran/Desktop/start.py
$ bin/manage shell --plain
Python 2.6.7 (r267:88850, Jul 31 2011, 19:30:54) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> datetime
Traceback (most recent call last):
  File "<console>", line 1, in <module>
NameError: name 'datetime' is not defined
>>> exit()
$ 
$ # Apply the diff
$ git apply ~/Desktop/PYTHONSTARTUP_support_in_shell_management_command.diff
$ 
$ bin/manage shell --plain
Python 2.6.7 (r267:88850, Jul 31 2011, 19:30:54) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> datetime
<module 'datetime' from '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/datetime.so'>

[Ramiro Morales]

Acceptung because AFAICS reading the file $PYTHONSTARTUP points to and .pythonrc.py as implemented when fixing #3381 was DOA.

[Ramiro Morales <cramm0@…>]

In 1f6b2e7a658594e6ae9507c5f98eb429d19c0c9d:

Fixed #6682 -- Made shell's REPL actually execute $PYTHONSTARTUP and ~/.pythonrc.py.

Also:

• Added a --no-startup option to disable this behavior. Previous logic to try to execute the code in charge of this funcionality was flawed (it only tried to do so if the user asked for ipython/bpython and they weren't found)
• Expand ~ in PYTHONSTARTUP value.

Thanks hekevintran at gmail dot com for the report and initial patch.

Refs #3381.