[long] bzr with wsgi and gunicorn vs Pylons (paste)

[Adrien Saladin]

> Date: Tue, 19 Oct 2010 08:58:58 -0500
> Subject: Re: [long] bzr with wsgi and gunicorn vs Pylons (paste)
>
> On 10/19/2010 8:12 AM, Adrien Saladin wrote:
>>
>> Now I can work with my foo branch with commands like:
>> $ bzr branch bzr+http://localhost:9000/bzr/foo
>>
>> note that using http instead of bzr+http results in a 404 error.
>>
>> Have I done things correctly up to now ?
>
> If you use "bzr command http://..." we will detect if there is a smart
> server running, and issue smart requests via POST. However, if we are
> just reading the content of a file, we issue a regular GET request. (so
> to read .bzr/branch-format we do a simple GET request for the file, to
> stream recorded data we issue a POST to .bzr/smart.)
>
> If you use bzr+http:// then we issue a POST to .bzr/smart for the plain
> file content as well.


OK, I see. "bzr branch" works for bzr+http and http alone. Only "bzr
log" fails with this setup using http only.
I can probably fix this...


>>
>> Now comes my problem, when I try to interface this server in a Pylons
>> application.
>> First I created a new controller called "bazaar". Then I replaced the
>> code for this controller by this:
>>
>> ##########  (extract of) controllers/bazaar.py
>> def BazaarController(environ, start_response):
>>     environ['REQUEST_URI']= environ['PATH_INFO']
>>
>>     app = wsgi.make_app(
>>             root="/home/adrien/bzr/",
>>             prefix="/bazaar/",             #<-- now using /bazaar/ as
>> the root URL
>>             readonly=True,
>>             enable_logging=False)
>>
>>     ret = app(environ, start_response)
>>     print "@@@returns@@@: ",ret
>>
>>     return ret
>>
>> #################
>
> ^- Is it valid to have "print ..." in the code? I don't know wsgi/pylons
> but I know a lot of web-appy stuff returns stdout back to the user.


Well, it's not very clean but works. It simply prints to the server's
stdout so I can inspect the content in a console.


>
>>
>> I also modified the config/routing.py for the special URLs from
>> bzr+http protocol:
>>
>> + map.connect("/bazaar", controller="bazaar")
>> + map.connect("/bazaar/{branchname:.*?}", controller="bazaar")
>>
>>
>> Now when I test this new setup, I have the following error from bzr (client):
>> $ bzr branch bzr+http://localhost:5000/bazaar/foo
>> bzr: ERROR: Invalid range access in
>> http://localhost:5000/bazaar/foo/.bzr/smart at 0: Can't read 28 bytes
>> across range (0, 25)
>>
>
> ^- This seems extra strange. This sounds like we are issuing a "GET"
> with a range header to .bzr/smart, which we shouldn't ever be doing. Did
> you try "bzr+http://..." with the same requests?


I don't get this one. Did you mean with http instead of bzr+http ?
$ bzr branch http://localhost:5000/bazaar/foo
bzr: ERROR: HTTP Error 404: Not Found

on the server side:

16:34:56,507 DEBUG [worker 0] [routes.middleware] Matched OPTIONS /bazaar/foo/
16:34:56,507 DEBUG [worker 0] [routes.middleware] Route path:
'/bazaar/{branchname:.*?}', defaults: {'action': u'index',
'controller': u'bazaar'}
16:34:56,507 DEBUG [worker 0] [routes.middleware] Match dict:
{'action': u'index', 'controller': u'bazaar', 'branchname': u'foo/'}
16:34:56,561 WARNI [worker 0] [bzr] Unable to load plugin 'git'. It
requested API version (2, 1, 0) of module <module 'bzrlib' from
'/home/adrien/virtualenvs/shabti0.4/lib/python2.6/site-packages/bzr-2.2.0-py2.6-linux-x86_64.egg/bzrlib/__init__.pyc'>
but the minimum exported version is (2, 2, 0), and the maximum is (2,
2, 0)
@@@returns:@@@  []
16:34:56,662 DEBUG [worker 0] [routes.middleware] Matched OPTIONS
/error/document
16:34:56,662 DEBUG [worker 0] [routes.middleware] Route path:
'/error/{action}', defaults: {'action': 'index', 'controller':
u'error'}
16:34:56,662 DEBUG [worker 0] [routes.middleware] Match dict:
{'action': u'document', 'controller': u'error'}
16:34:56,671 DEBUG [worker 1] [routes.middleware] Matched POST
/bazaar/foo/.bzr/smart
16:34:56,671 DEBUG [worker 1] [routes.middleware] Route path:
'/bazaar/{branchname:.*?}', defaults: {'action': u'index',
'controller': u'bazaar'}
16:34:56,671 DEBUG [worker 1] [routes.middleware] Match dict:
{'action': u'index', 'controller': u'bazaar', 'branchname':
u'foo/.bzr/smart'}
@@@returns:@@@  ['error\x01incomplete request\n']
16:34:56,678 DEBUG [worker 2] [routes.middleware] Matched GET
/bazaar/foo/.bzr/branch-format
16:34:56,678 DEBUG [worker 2] [routes.middleware] Route path:
'/bazaar/{branchname:.*?}', defaults: {'action': u'index',
'controller': u'bazaar'}
16:34:56,678 DEBUG [worker 2] [routes.middleware] Match dict:
{'action': u'index', 'controller': u'bazaar', 'branchname':
u'foo/.bzr/branch-format'}
@@@returns:@@@  []
16:34:56,681 DEBUG [worker 2] [routes.middleware] Matched GET /error/document
16:34:56,681 DEBUG [worker 2] [routes.middleware] Route path:
'/error/{action}', defaults: {'action': 'index', 'controller':
u'error'}
16:34:56,681 DEBUG [worker 2] [routes.middleware] Match dict:
{'action': u'document', 'controller': u'error'}
16:34:56,769 DEBUG [worker 3] [routes.middleware] Matched GET /bazaar/foo/
16:34:56,769 DEBUG [worker 3] [routes.middleware] Route path:
'/bazaar/{branchname:.*?}', defaults: {'action': u'index',
'controller': u'bazaar'}
16:34:56,769 DEBUG [worker 3] [routes.middleware] Match dict:
{'action': u'index', 'controller': u'bazaar', 'branchname': u'foo/'}
@@@returns:@@@  []
16:34:56,771 DEBUG [worker 3] [routes.middleware] Matched GET /error/document
16:34:56,772 DEBUG [worker 3] [routes.middleware] Route path:
'/error/{action}', defaults: {'action': 'index', 'controller':
u'error'}
16:34:56,772 DEBUG [worker 3] [routes.middleware] Match dict:
{'action': u'document', 'controller': u'error'}



>
> error\x01incomplete request\n is the smart servers way of saying there
> was a problem. The client code should be handling that and raising an
> appropriate error internally.
>
> So the question is why is pylons + whatever not returning the content,
> and instead erroring?
>

But is this message part of the normal workflow. I thought the
question was "why does the bzr wsgi app returns an error message given
its input" ?

Thanks,
Adrien