Django

Code

Ticket #5825 (closed: fixed)

Opened 1 year ago

Last modified 4 months ago

Customized actions for manage.py not working

Reported by: jdetaeye@frepple.com Assigned to: nobody
Milestone: 1.0 Component: django-admin.py
Version: SVN Keywords: custom actions manage.py
Cc: eric@akoha.org, martin@akoha.org, micsco@gmail.com, elsdoerfer@gmail.com, ehs@pobox.com Triage Stage: Ready for checkin
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Custom actions can be added, as described http://www.djangoproject.com/documentation/django-admin/#customized-actions Following the instructions I am getting the error message: unknown command

To reproduce you can also copy the contents of the folder tests\modeltests\user_commands\management in an application subdirectory of your project.
The regression test for user_commands passes: it seems to use a different sys.path than when you run manage.py from the commandline...

Digging a bit deeper in the source file django\core\management\__init__.py :

- The function imp.find_module in the method find_management_module is using sys.path to locate the management modules. The parent directory of your project is normally not on the path, so looking for an application package "project_name.app_name" doesn't find a module. Manage.py only has the project directory itself on the path.

- The find_commands method in the same source file is using a pretty hack-ish way to discover commands: it looks for files ending in .py. This misses compiled code with extensions as .pyo and .pyc and also doesn't work for source files packaged in a zip file (as produced by eg py2exe). The correct api is to use pkgutil.iter_modules (unfortunately only available in python 2.5)

(I'm willing to look at a patch for the issues, but need some guidance: For the first issue, I am a bit puzzled by the append and popping of the sys.path in the setup_environ method in the same file. For the second issue, it requires more changes and thinking to do it properly across different versions: is it worth the effort?)

Attachments

usercommands.patch (4.1 kB) - added by jdetaeye@frepple.com on 11/26/07 11:51:45.
Patch
usercommands.2.patch (4.1 kB) - added by jdetaeye@frepple.com on 11/26/07 11:51:47.
patch
user_commands_path.patch (1.4 kB) - added by andrew.mcmurry@astro.uio.no on 11/27/07 04:09:10.
Here is a very simple patch that will make sure that sys.path includes the project's containing directory while searching for the local app management modules.
user_command_with_test.patch (2.1 kB) - added by abozanich on 05/28/08 00:06:34.

Change History

11/09/07 02:17:10 changed by alexander.pugachev@gmail.com

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

In django.core.management.init.py in find_management_module function to define path to management module of each application (user app as well as django core) used function find_module from standard imp. Function find_module is called iterately on each part of application name with project name. If application is called "common", and project is called "holdem" then find_module first tries to import "holdem", then using it's path tries to import "common", then using it's path tries to import "management". Before first call of find_module path is set to None. This makes find_module to use "clean" sys.path on start. In that sys.path project dirname itself appears, but it's parent directory does not. Which is required to import user application whose name is starts from project name. I added to my project settings.py lines

{{{import os, sys sys.path.append(os.path.dirname(os.getcwd()))}}}

This makes manage.py to see management commands added by user applications. I think that project parent directory appending have to be done by manage.py if that directory is not in sys.path.

11/09/07 02:50:26 changed by alexander.pugachev@gmail.com

import os, sys sys.path.append(os.path.dirname(os.getcwd()))

11/09/07 02:50:59 changed by anonymous 

import os, sys 
sys.path.append(os.path.dirname(os.getcwd()))

how formatting works?

11/21/07 07:29:13 changed by anonymous

The correct directory is added to sys.path by the django.core.management.setup_environ() function. It is then, for some reason, removed again. Why is this function called, if not to setup the sys.path correctly?

Commenting out the line: 'sys.path.pop()' from this function will make customized actions work correctly.

11/26/07 11:33:08 changed by anonymous

  • owner changed from nobody to jdetaeye.

11/26/07 11:51:45 changed by jdetaeye@frepple.com

  • attachment usercommands.patch added.

Patch

11/26/07 11:51:47 changed by jdetaeye@frepple.com

  • attachment usercommands.2.patch added.

patch

11/26/07 11:52:27 changed by anonymous

  • has_patch set to 1.

11/27/07 04:09:10 changed by andrew.mcmurry@astro.uio.no

  • attachment user_commands_path.patch added.

Here is a very simple patch that will make sure that sys.path includes the project's containing directory while searching for the local app management modules.

12/01/07 21:59:12 changed by Simon G <dev@simon.net.nz>

  • stage changed from Unreviewed to Ready for checkin.

12/01/07 21:59:30 changed by Simon G <dev@simon.net.nz>

#6013 was marked as duplicate

12/04/07 13:57:50 changed by jacob

  • needs_tests set to 1.
  • stage changed from Ready for checkin to Accepted.

12/04/07 15:10:11 changed by jdetaeye

  • owner changed from jdetaeye to nobody.

I fully agree that the testing for manage.py and django-admin.py can be better. The current test suite elegantly bypasses them.

There is already a unit test for user commands, and I don't clearly see how I can improve on it: hence I'm removing myself as the owner of the issue. Maybe somebody else has some bright idea or view on this...

05/28/08 00:06:34 changed by abozanich

  • attachment user_command_with_test.patch added.

05/28/08 00:07:05 changed by abozanich

I came across this bug as well over the weekend. Attached is a small patch (the current one here no longer applies) & a unit test for the fix.

06/17/08 10:40:29 changed by wiswaud

  • cc set to eric@akoha.org.

06/17/08 10:53:58 changed by martin

  • cc changed from eric@akoha.org to eric@akoha.org, martin@akoha.org.

07/25/08 00:25:43 changed by anonymous

  • cc changed from eric@akoha.org, martin@akoha.org to eric@akoha.org, martin@akoha.org, micsco@gmail.com.

07/25/08 00:27:54 changed by anonymous

  • needs_tests deleted.
  • stage changed from Accepted to Ready for checkin.

07/25/08 00:36:13 changed by anonymous

#6128 was marked as duplicate

07/25/08 06:30:17 changed by russellm

  • milestone set to 1.0.

This is a sufficiently significant problem that it warrants attention before v1.0

08/03/08 15:34:43 changed by miracle2k

  • cc changed from eric@akoha.org, martin@akoha.org, micsco@gmail.com to eric@akoha.org, martin@akoha.org, micsco@gmail.com, elsdoerfer@gmail.com.

08/07/08 18:35:22 changed by edsu

Patch works for me. Would love to see this checked in.

08/07/08 19:40:29 changed by edsu

  • cc changed from eric@akoha.org, martin@akoha.org, micsco@gmail.com, elsdoerfer@gmail.com to eric@akoha.org, martin@akoha.org, micsco@gmail.com, elsdoerfer@gmail.com, ehs@pobox.com.

08/08/08 07:27:40 changed by russellm

  • status changed from new to closed.
  • resolution set to fixed.

(In [8227]) Fixed #5825 -- Modified the custom command loader to allow for explicit specification of the project name, even if the project directory isn't in the python path. This brings custom command loading into alignment with application loading. Thanks to jdetaeye@frepple.com for the original report, and to abozanich for the patch.

08/13/08 02:12:11 changed by jdetaeye

A new ticket ##8280 was created to make sure the commands framework supports alternate ways of packaging.
The original patch on this ticket fixed that problem too.

Add/Change #5825 (Customized actions for manage.py not working)




Change Properties
Action