Code

Opened 6 years ago

Closed 18 months ago

#6682 closed Uncategorized (fixed)

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

Reported by: olau@… Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Normal Keywords: feature shell ipython
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Attachments (2)

ipy_profiles.py (2.1 KB) - added by edcrypt 6 years ago.
PYTHONSTARTUP_support_in_shell_management_command.diff (1.4 KB) - added by hekevintran@… 18 months ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

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

comment:2 Changed 6 years ago by 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'>
>>>

comment:3 Changed 6 years ago by Ole Laursen <olau@…>

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 6 years ago by edgarsj

  • Keywords feature added
  • Triage Stage changed from Unreviewed to Design decision needed

comment:5 Changed 6 years ago by edcrypt

  • Keywords shell ipython added

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.

comment:6 Changed 6 years ago by 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.

Changed 6 years ago by edcrypt

comment:7 Changed 6 years ago by edcrypt

  • Has patch set
  • Needs documentation set
  • Patch needs improvement set

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.

comment:9 Changed 5 years ago by 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.)

comment:10 Changed 5 years ago by russellm

  • Resolution set to wontfix
  • Status changed from reopened to closed

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.

comment:11 Changed 5 years ago by olau

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.

Changed 18 months ago by hekevintran@…

comment:12 Changed 18 months ago by hekevintran@…

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

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

comment:13 Changed 18 months ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to new

comment:14 Changed 18 months ago by ramiro

  • Triage Stage changed from Design decision needed to Accepted

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

Version 0, edited 18 months ago by ramiro (next)

comment:15 Changed 18 months ago by Ramiro Morales <cramm0@…>

  • Resolution set to fixed
  • Status changed from new to closed

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.