Opened 9 years ago

Closed 7 years ago

#11518 closed Bug (fixed)

Custom commands cannot be run from cron (or other directory) if project is not on Python Path

Reported by: mark.ellul@… Owned by: nobody
Component: Core (Other) Version: 1.1-beta
Severity: Normal Keywords: custom commands
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


If I wanted to create a custom command say in application a custom command to get_latest_weather and wanted to run that in a cron job it would fail if myproj is not on the PYTHON PATH.

I am using Python 2.6 and the imp.find_module is not finding the project path.

I can see the project module does indeed exist in sys.modules

Attachments (1)

patch.txt (633 bytes) - added by Mark <mark.ellul@…> 9 years ago.
patch for this fix

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by Mark <mark.ellul@…>

When I insert the code below at line 56 (in the ImportError exception handling) in at django/core/management/ it resolves the issue

if sys.modules.has_key(part):
   path = os.path.realpath(sys.modules[part].__path__[0])
elif os.path.basename(os.getcwd()) != part:
   raise e   

Hope that helps.

comment:2 Changed 9 years ago by anonymous

Resolution: worksforme
Status: newclosed

comment:3 Changed 9 years ago by Mark <mark.ellul@…>

Resolution: worksforme
Status: closedreopened


Maybe I was not being specific enough...

If you create a custom command in an app in your project myproj/myapp1/management/commands/ and then try to use the call_command from the


from import call_command

and your project is not on the PYTHONPATH, you will get a failure, because imp.find_module is not finding the myproj module that is loaded in memory.

If you add the fragment I have already mentioned it will search the sys.modules dictionary, where it does find the project's loaded module.

Please let me know if you need more details.



Changed 9 years ago by Mark <mark.ellul@…>

Attachment: patch.txt added

patch for this fix

comment:4 Changed 9 years ago by Russell Keith-Magee

milestone: 1.1

This isn't a blocker for v1.1.

comment:5 Changed 9 years ago by mark.ellul@…

Has patch: set

I agree not a blocker, Sorry I didn't understand the milestone setting properly!

Its a weird edge case bug, easily fixed though

comment:6 Changed 9 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

comment:7 Changed 8 years ago by Julien Phalip

Severity: Normal
Type: Bug

comment:8 Changed 7 years ago by Łukasz Rekucki

Easy pickings: unset
Triage Stage: AcceptedReady for checkin
UI/UX: unset

Looks good, although getting rid of the terrible hack on PYTHON_PATH would be even better.

comment:9 Changed 7 years ago by Aymeric Augustin

I'm struggling to understand what this change actually does :/

comment:10 Changed 7 years ago by Luke Plant

Resolution: fixed
Status: reopenedclosed

AFAICS, the bug can happen only when you are using the old sys.path hack that we used to use, in which a module in your project could be importable as 'myproj.myapp.mymodule' and 'myapp.mymodule'. I'm marking FIXED on that basis, since we've removed/deprecated the sys.path hack -

Note: See TracTickets for help on using tickets.
Back to Top