manage testserver and manage runserver should have similiar address:port options

[wildfire@…]

Hi,

$ ./manage.py runserver -h
Usage: ./manage.py runserver [options] [optional port number, or ipaddr:port]

Starts a lightweight Web server for development.

[...]

$ ./manage.py testserver -h
Usage: ./manage.py testserver [options] [fixture ...]

In order to get the testserver to listen on a particular port, you need to specify the --addrport option.

It would be useful if that option was also understood by the normal runserver command. Or if testserver interpreted a bare port number as the runserver command does.

[Fede Heinz]

This patch implements the requested feature

[Fede Heinz]

The attached patch implements and documents the requested feature. For backwards compatibility, both runserver and testserver now accept both ways of specifying the IP address.

[Fede Heinz]

14332

[Ramiro Morales]

Reopening. The fixed status is set when a commit lands in the code repository.

[Łukasz Rekucki]

I'm against doing it this way. I see no value for having --addrport option for runserver. Duplicating functionality is a bad thing, imho (You know, "there should be one obvious way to do it", etc.). A minor backwards compatibility issue is that someone can have a fixture named "1000", which will now get interpreted as port number.

If I was to propose something, it would be deprectating --addrport and runserver's positional syntax in favour of --host and --port options. That would at least be consistent with most UNIX tools, but I'm generally -0 on changing anything here.

[Fede Heinz]

I agree that "there should be one obvious way to do it" is a Good Thing. What we have now is "there are two incompatible ways to do it, and you must choose the right one or it won't work".

The change you propose would give us indeed one way to do it, at the price of breaking backwards compatibility for *both* runserver and testserver.

I know that the current implementation doesn't work if you absolutely need to give a fixture a numerical name without extension, and put it first in the list of fixtures. That is an unlikely use case, and the --addrport option saves the day anyway.

The way I see it, of the three option that are on the table right now (providing a homogeneous interface that breaks backwards compatibility, providing a homogeneous but redundant user interface without breaking backwards compatibility, and leaving things as they are with an redundant and inconsistent interface), the patch implements the least objectionable one.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

runserver is about 10000x more used that testserver.

I'm -1 on making changes to runserver (especially changes towards a longer syntax) only to provide consistency with an obscure command few developers use.

I'm not very excited either by special casing the first argument to testserver to magically determine if it's a binding spec or a fixture name, such hacks backfire too often.

Please take it to django-developers to see if there's actual demand for changes, the current situation doesn't seem horrific to me. testserver needs arguments, runserver doesn't, that's it.