Issue #636 resolved

Move into a subdirectory for cleaner svn:externals links

Anonymous created an issue

I'd like to see housed in its own subdirectory (its own python package, I guess. simply copy cherrypy/ to cherrypy/wsgiserver/ or something) in the cherrypy repository, to allow clean svn:externals links to it. This would be for WSGI projects that want to incorporate only

Unfortunately svn:externals only allows links to directories, not files. So currently projects that want just wsgiserver have three options:

1) svn:externals the entire cherrypy directory. Every checkout/update of their project will now check out all of the cherrypy project

2) require the cherrypy package to be installed. This is what I did for PasteScript (it now has a cherrypy wsgiserver entry point). This in theory wasn't a big deal, then I realized that having the cherrypy package installed and importing wsgiserver incurs loading a good deal of cherrypy code (due to cherrypy/

wsgiserver doesn't require any of this -- but not only is loading overkill, it breaks the expected handling of signals. loads (among other things) in turn causing the custom cp signal handlers to be installed. Sending a HUP to the process running causes a call to cherrypy.engine.reexec():

{{{ [04/Jan/2007:12:19:33] ENGINE Re-spawning /usr/local/bin/paster serve pjenvey.ini Traceback (most recent call last): File "/usr/local/bin/paster", line 7, in ? execfile(file) File "/usr/home/pjenvey/src/python/paste/PasteScript/scripts/paster", line 18, in ? File "/usr/home/pjenvey/src/python/paste/PasteScript/paste/script/", line 76, in run invoke(command, command_name, options, args[1:]) File "/usr/home/pjenvey/src/python/paste/PasteScript/paste/script/", line 115, in invoke exit_code = File "/usr/home/pjenvey/src/python/paste/PasteScript/paste/script/", line 210, in run result = self.command() File "/usr/home/pjenvey/src/python/paste/PasteScript/paste/script/", line 199, in command server(app) File "/usr/home/pjenvey/src/python/paste/PasteDeploy/paste/deploy/", line 139, in server_wrapper wsgi_app, context.global_conf, File "/usr/home/pjenvey/src/python/paste/PasteDeploy/paste/deploy/util/", line 57, in fix_call val = callable(args, *kw) File "/usr/home/pjenvey/src/python/paste/PasteScript/paste/script/", line 95, in cpwsgi_server server.start() File "/usr/home/pjenvey/src/python/cherrypy/cherrypy/wsgiserver/", line 825, in start raise socket.error, msg socket.error: (48, 'Address already in use') }}}

This problem will also occur with option 1

3) Copy into their own repository. This gets you the isolation, but a clean svn:externals link would be more convenient

I noticed the Aspen project ( ) uses cherrypy.wsgiserver exclusively as its WSGI server. They've gone with option #3. They've already made a couple changes to their version of wsgiserver, and they appear to be only whitespace. Doh!

The svn:externals link might discourage these unnecessary 'forks' of the code, hopefully encouraging any changes that have to be done to wsgiserver to be generic in nature and go back upstream to you guys, when appropriate.

Since wsgiserver is already used by at least 2 projects a week after 3.0.0 was released, I suspect there will be more projects in the future that would utilize/benefit from this change =]

Reported by

Comments (4)

  1. Anonymous

    Thanks for noticing re: Aspen. The whitespace changes crept in because I automatically trim trailing whitespace. Sorry. My intention is to use unmodified, which I've recently noted in the [ README]. I'll [ clean up the whitespace] too.

    I actually try pretty hard not to change the module, instead I [ extend CherryPyWSGIServer via monkey-patching] (find 'Server.tick').

    In the case of actual bugs, it's part of the open source social contract that any fixes would be pushed upstream. However, it's just as easy to generate a patch from one svn repo as another. CP shouldn't accept my patches w/o review, and in the mean time I'd presumably need to use the fix myself, so I think w/ bug fixes a ''little'' forking is ok. That's just some slack in the line while changes get pushed upstream.

    Lastly, regarding svn:externals: to be honest, I wouldn't use it. First, I'd rather store bits twice than introduce extra complexity and network traffic, especially for a single module. Second, I want more control over dependency versions. For example, upgrading to 3.0.0/ took me several hours because of a change in the way an unspecified hostname is handled (now defaulting to AF_INET6 instead of AF_INET). I want to be in control of that decision to upgrade.

    But since I could still go with option 3 even with this change, I'm at -0 on it.

  2. Anonymous

    Chad - no need to apologize, I figured it was an unintentional 'fork' =] In fact I forgot to CC: you on this ticket (I was intending to)

    There'll definitely be cases when copying the code is more appropriate. I personally don't think there's that much extra network traffic involved in svn:externals worth worrying about, so I'd always prefer to use svn:externals unless I need to copy. Though I understand where you're coming from.

    I'll also point out that you can always link to a stable release's tag to ensure the correct dependency, as long as the source repository is tagging releases and not using tags as branches (which most projects seem to do).

  3. Log in to comment