Am I missing something here? You can specify the port in the standard way like this:
./manage.py runserver 0.0.0.0:12345 or ./manage.py runserver 192.168.2.29:45001 Is this not working for you? It's all documented right here: http://www.djangoproject.com/documentation/django-admin/#runserver-optional-port-number-or-ipaddr-port Hope that helps! Clint On 8/28/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > The testserver command doesn't currently allow you to set the port for > the server to run on. I teach high school in a Linux thin client lab, so > all of my students are running on the same server and each needs his/her > own port, unfortunately. (Interestingly, having 10-15 Django dev servers > running simultaneously on a quad-core Opteron with 8GB of memory while > it's busy serving 30 Gnome desktops isn't really a problem.) > > I can see two ways to add the ability: > > 1. (the easy and clean but hackish way) > Check the first arg to see if it's an integer and, if so, assume it's > the port specification. This only involves adding an if inside > testserver's handle method. But it means that you can't list a fixture > with a name that happens to be an integer as the first fixture after the > testserver command. > > 2. (the more robust, but more involved way) > Add a --port option that testserver could use. The problem is that this > means adding another option to django.core.management.ManagementUtility > since each option currently has to be added globally. Adrian has a > comment that it would be ideal to allow each command to register its own > options, but that optparse checks for conflicts, so that doesn't work so > well. > > Here's a suggestion to pull the options out of > django.core.management.ManagementUtility: What if we just read the > command after manage.py/django-admin.py and then passed the rest of the > parsing to a separate execute method for each Command subclass. I'm > envisioning something like > > class Command(BaseCommand): > options = { 'option_name': dict_for_kwargs_to_add_option } > > In the execute method of Command, we'd build up the options for the > particular command, including any options from superclasses (like > --settings, which I think every command can use). > > Since this would pull apart all the options, it seems like it would > allow you to do something like what svn does. Have a 'help' command that > lists each possible command and then for 'help foo' print the usage for > that particular command, including options, etc. > > If this seems like an elegant solution and is something people would be > interested in, I can probably code it up this afternoon. (I teach until > about 1:00 Eastern when my planning period starts.) > > If this seems too involved, I'm open to other ideas! > Todd > > > > > -- Clint Ecker Sr. Web Developer - Stone Ward Chicago p: 312.464.1443 c: 312.863.9323 --- twitter: clint skype: clintology AIM: idiosyncrasyFG Gtalk: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
