Re: support for custom django-admin commands written as packages

[Marwan Al-Sabbagh]

I agree with many of your points. It would be nice if Django did not deal
with the file system directly but just imports the packages. There have been
some efforts to do custom commands in a better way. there is the project
django-boss https://github.com/zacharyvoase/django-boss which stemmed out of
this blog post http://blog.zacharyvoase.com/2009/12/09/django-boss/. Zachary
Voase runs through a number of things that could be improved in the way
custom commands work.
I though did want to use the django-admin custom commands and so an
opportunity to make it more flexible in who you implement the commands. When
I had a look at the code I saw this was possible by making a small change to
one function, so I felt it didn't add much complexity to the existing
system. I've a ticket with the patch at
https://code.djangoproject.com/ticket/16167. Thanks for the feedback, and I
would be open to helping improve the whole way custom commands as a whole
work in Django too.

Marwan

On Mon, Jun 6, 2011 at 9:31 PM, Carl Meyer  wrote:

> Hi Marwan,
>
> On 06/05/2011 10:15 AM, Marwan Al-Sabbagh wrote:
> > Hello,
> >   Currently one can create a custom command by implementing a Command
> > object in a python module such as
> > "polls/management/commands/closepoll.py". It would be great if Django
> > also supported these commands being implemented in a python package so
> > in this case Command would be found in
> > "polls/management/commands/closepoll/__init__.py". This would be
> > useful when a command contains a lot of logic or code and the
> > developer would like the ability to split up the logic into multiple
> > files to make the code base more manageable. I faced this issue
> > recently when I implemented a command that would be run as a cron job
> > to periodically import data into Django from a legacy system that had
> > some pretty hairy logic to deal with.
> >I've already made the changes to support the feature, it only
> > required a change to the function
> > django.core.management.find_commands() to look for packages as well as
> > modules in each commands directory. I thought I'd run it by
> > django-developers before creating the ticket on trac with the patch.
> > What do you guys think?
>
> I'm not a big fan of the way Django finds management commands. Searching
> directly on the filesystem makes Django apps with management commands
> incompatible with legitimate builtin Python features such as import
> hooks or zipfile imports. IMHO, regardless of what you think of those
> Python features, this makes Django somewhat less than "just Python."
>
> That said, I don't have a great alternative in mind at the moment, but I
> don't like the idea of taking the current bad system and extending it
> with even more complexity.
>
> Generally my approach to the problem you describe is to make the
> management command itself a minimal wrapper around the core code,
> implemented as functions and classes within appropriately-named
> submodules of the app itself, not within the
> myapp.management.commands.mycommand namespace. I almost always at some
> point want to reuse that code as library code, so I actually find it
> preferable if the bulk of the code lives outside the management.commands
> namespace, and is just imported and used by the management command. This
> can also encourage a separation of responsibilities that makes testing
> easier.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: support for custom django-admin commands written as packages

[Carl Meyer]

Hi Marwan,

On 06/05/2011 10:15 AM, Marwan Al-Sabbagh wrote:
> Hello,
>   Currently one can create a custom command by implementing a Command
> object in a python module such as
> "polls/management/commands/closepoll.py". It would be great if Django
> also supported these commands being implemented in a python package so
> in this case Command would be found in
> "polls/management/commands/closepoll/__init__.py". This would be
> useful when a command contains a lot of logic or code and the
> developer would like the ability to split up the logic into multiple
> files to make the code base more manageable. I faced this issue
> recently when I implemented a command that would be run as a cron job
> to periodically import data into Django from a legacy system that had
> some pretty hairy logic to deal with.
>I've already made the changes to support the feature, it only
> required a change to the function
> django.core.management.find_commands() to look for packages as well as
> modules in each commands directory. I thought I'd run it by
> django-developers before creating the ticket on trac with the patch.
> What do you guys think?

I'm not a big fan of the way Django finds management commands. Searching
directly on the filesystem makes Django apps with management commands
incompatible with legitimate builtin Python features such as import
hooks or zipfile imports. IMHO, regardless of what you think of those
Python features, this makes Django somewhat less than "just Python."

That said, I don't have a great alternative in mind at the moment, but I
don't like the idea of taking the current bad system and extending it
with even more complexity.

Generally my approach to the problem you describe is to make the
management command itself a minimal wrapper around the core code,
implemented as functions and classes within appropriately-named
submodules of the app itself, not within the
myapp.management.commands.mycommand namespace. I almost always at some
point want to reuse that code as library code, so I actually find it
preferable if the bulk of the code lives outside the management.commands
namespace, and is just imported and used by the management command. This
can also encourage a separation of responsibilities that makes testing
easier.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.