pa_create_webapp_with_virtualenv.py missing docopt arg <git-repo-url> -> KeyError

[javabrett]

pa_create_webapp_with_virtualenv.py is expecting a <git-repo-url> like the Django script, but it's not docopt specified, so a KeyError ensues:

Traceback (most recent call last):
  File "scripts/pa_create_webapp_with_virtualenv.py", line 51, in <module>
    main(arguments['<git-repo-url>'], arguments['--domain'], arguments['--python'], nuke=arguments.get('--nuke'))
KeyError: '<git-repo-url>'

Even if <git-repo-url> is added to the docopt spec, the variable isn't currently used for checkout like it is in the Django version.

[gpjt]

Good catch -- I've removed that entirely, as it's not something the script needs.

[javabrett]

@gpjt Interesting - I had started on some changes to make <git-repo-url> expected and allowed ... otherwise there's no hook to check-out source for the site. That said, the current hook is pretty limited - it's just a git clone with no way to specify a branch or tag, so is incomplete.

What I next found was that for a free-form project (such as you might want to launch with this script), you are probably going to need some custom logic to populate the virtualenv ... this logic is currently sitting in the Django project subclass e.g. detect_requirements ... (assumes a single requirements.txt for pip I think.

So I think some refactoring is required as some of this stuff is not Django-specific.

And I think an interface will be needed for provide a WSGI file rather than trying to always build one from a template.

[gpjt]

Agreed, the script could definitely do more than it currently does! Still, at least it's not completely broken now -- that's a better starting point for adding enhancements than before.

So how about:

• It takes an optional git repo URL
• If that is specified, it checks it out to some sensible place (I think our Django autoconfigure one uses the domain name as the directory name)
• It looks in the repository for a requirements.txt and if it finds one, it pip installs everything from it (like you say, this could be refactored from the django project class.

Of course, an ideal script would try to work out which web framework you were using and populate the WSGI file based on that. But I suspect that would be really hard to do in a reliable fashion. In particular, Flask and Bottle are so free-form that the WSGI application object could be pretty much anywhere.

Perhaps this script could be the basic one that further pa_autoconfigure_flask.py, pa_autoconfigure_bottle.py, and pa_autoconfigure_web2py.py scripts could build on (and pa_autoconfigure_django.py could be refactored to build on too)? The Bottle and Flask ones might require parameters to say "this is the file where my app object is defined" and perhaps also "this is the name I've given to my app object, because I decided not to call it app"?