[Web-SIG] A more useful command-line wsgiref.simple_server?

[Sasha Hart]

My 2c on the idea - I like this as a way to reduce friction a little
for beginners who just want to see their web apps run and may not be
comfortable enough to install something else. It would be nice to have
a one-liner with no non-stdlib dependencies, like 'python -m
SimpleHTTPServer' for running WSGI. But I probably won't be using it
much: if you can type (say) 'pip install gunicorn' then 'gunicorn app'
is ridiculously easy (not to specifically promote gunicorn, it's just
an example).

On Thu, Mar 29, 2012 at 1:14 PM, Masklinn <masklinn at masklinn.net> wrote:
>
> On 2012-03-29, at 19:46 , PJ Eby wrote:
> > * drop the ':' separator syntax, or else use os.pathsep so that it works
> > properly on Windows (where ':' can denote a drive letter)
>
> Ah yes, I had not thought of that, this would be annoying and I don't
> think the pathsep helps, since the script is an arbitrary path file it
> can contain pathseps. A second — optional as well — positional parameter
> would avoid that problem, would not be more typing and would remove the
> need for some of the munging in the type callable.
>
> But now that'd look weird with -m module, unless `-m` is not an
> option-with-value but a boolean flag saying to treat the first
> positional parameter as a module instead of a script.


If the colon can be made safe for Windows it might be desirable, since
it looks fine and reflects existing practice in a number of places.
But aside from that, I really hope os.pathsep won't be used, because
then we will have a format for naming a WSGI app object which not only
differs from established practice, but (worse) depends on the platform
in a non-obvious way (i.e., not just like using os.sep when specifying
paths on platform-specific file system, which is normal for people who
type out file paths)

As I understand (please correct me if I'm wrong), the big obvious
problem for Windows is that simply splitting on ':' will do something
dumb if the path is something like 'C:\app.py' or
'D:\work\company.apps:foo'. That parsing issue can be worked around
for normal cases, but the ambiguous corner cases like 'c:app' are
confusing (that could be either a file 'app' on the root of the C:
drive, or a callable named 'app' in the module c - unfortunately the \
is not required to specify the root).

So if you want to both keep the colon and want to accept all strings
which DOS would accept before the colon, you must disambiguate which
one you want to parse. But if you can part with the colon OR with the
'c:app' corner case, it can be managed.

Here are some alternative suggestions, in case they are helpful.

(A) accept only one of the two types of input at all (e.g. insist only
on importable module name - it looks like this is what gunicorn does
and I like it a lot - short of having your code installed on system
PYTHONPATH, or using virtualenv PYTHONPATH, you can also do this if
you are in the directory of the script/package)

(B) use --file=c:\app.py or similar to disambiguate what kind of
parsing to do - then the typical case can be the importable and users
who really want to refer to files explicitly can do so

(C) make an executive decision to interpret 'c:app' as object 'app' in
module 'c', require roots to be specified like 'c:\',
and split from the rightmost : not trailed by \. I believe this only
makes a problem in the incredibly specific pathological case where a
DOS-savvy windows user is trying to serve a file without an extension
directly out of root, while naming root unusually without using the
conventional \. and that rare case would generally just generate a
'huh?' - with the exception that the diabolical user made
single-letter modules with the same letters as drives and dumped them
on PYTHONPATH... I think this would work, just be more complex than
the (A) and (B) solution which seems to jibe more with the rest of
Python. but if you want to allow files to be specified freely in the
same spot that modules might be specified...

(D) give up colon: first arg is a filepath-or-pythonmodulepath, and
use something like --name=app (defaults to 'application' if not
specified) to add the app name to look for in the module... I'm not
too keen on this, it is almost as much extra typing as 'pip install'
for a very typical case. The colon is nice because it's one keystroke
and you can expect to use it

(E) give up colon: first arg is a filepath-or-pythonmodulepath, and
optional second arg is what would have come after the colon. I think
this is your suggestion and it's not unreasonable at all. If we are
talking about 'python -m wsgiref.simple_server c:app app' then the
second positional arg is definitely not the weirdest looking part. I
just question whether it's really necessary - why not either drop the
implicit specification of a filename (A/B) or enforce backslash after
root on windows (C)?