Help?! - Re: [Changeset] r5923 - django/trunk/django/core/management

2 views
Skip to first unread message

Malcolm Tredinnick

unread,
Aug 18, 2007, 1:33:03 AM8/18/07
to django-d...@googlegroups.com
Russ,

On Fri, 2007-08-17 at 23:51 -0500, nor...@djangoproject.com wrote:
> Author: russellm
> Date: 2007-08-17 23:51:51 -0500 (Fri, 17 Aug 2007)
> New Revision: 5923
>
> Modified:
> django/trunk/django/core/management/__init__.py
> Log:
> Added the ability for end users to register commands with management.py.
>
>
> Modified: django/trunk/django/core/management/__init__.py
> ===================================================================
> --- django/trunk/django/core/management/__init__.py 2007-08-18 04:16:04 UTC (rev 5922)
> +++ django/trunk/django/core/management/__init__.py 2007-08-18 04:51:51 UTC (rev 5923)
> @@ -7,13 +7,25 @@
> # For backwards compatibility: get_version() used to be in this module.
> get_version = django.get_version
>
> -def load_command_class(name):
> +def find_commands(path):
> """
> + Given a path to a management directory, return a list of all the command names
> + that are available. Returns an empty list if no commands are defined.
> + """
> + command_dir = os.path.join(path, 'commands')
> + try:
> + return [f[:-3] for f in os.listdir(command_dir) if not f.startswith('_') and f.endswith('.py')]
> + except OSError:
> + return []
> +
> +def load_command_class(module, name):

I don't understand this change completely yet, so I can't see the fix
you might intend. Short version, it doesn't seem to work for default
commands. The obvious example being that the tests break. call_command()
in __init__.py calls load_command_class(), but it doesn't pass in the
module. What should "module" be in this case?

Regards,
Malcolm

--
A conclusion is the place where you got tired of thinking.
http://www.pointy-stick.com/blog/

Russell Keith-Magee

unread,
Aug 18, 2007, 2:00:49 AM8/18/07
to django-d...@googlegroups.com
On 8/18/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
>
> I don't understand this change completely yet, so I can't see the fix
> you might intend. Short version, it doesn't seem to work for default
> commands. The obvious example being that the tests break. call_command()
> in __init__.py calls load_command_class(), but it doesn't pass in the
> module. What should "module" be in this case?

Bother. I'm having a really good few days, aren't I.

I completely forgot about the consequences to call_command. There
isn't a trivial fix, so I've rolled this back out in [5929] until I
(or someone else) can do this properly.

Apologies for the mess. I'll be in the corner hitting myself over the
head with a copy of Kent Beck's 'Test Driven Development' if you need
me.

Russ %-)

Reply all
Reply to author
Forward
0 new messages