Package for Standalone WSGI Server?

[Randy Syring]

I was wondering if the CherryPy devs would be willing to package the
CherryPy WSGI HTTP server into a separate package. Keep the current
package just like it is, but produce a second (maybe called
"CherryPyServer") that would simply be cherrypy.wsgiserver. I am
using the CherryPy server for some production sites and want to use
pip to specify all the packages I need. But I currently can't do that
without either a) rolling my own package or b) downloading all of
CherryPy. I can do "a" if needed, but just thought I might suggest it
to you first to see if you would be interested.

Thanks.

[Robert Brewer]

I'm not sure about the details of pip, but I do know several other
packages, and even some frameworks, use svn:externals to grab just the
wsgiserver. Would that implement your use cases?

Robert Brewer
fuma...@aminus.org

[Randy Syring]

Robert,

Thank you for the reply. While it is true that SVN could be used to
grab just the wsgiserver server directory and contents, PIP needs a
package with a setup.py file to install. So,

pip -E . install CherryPy

and

pip -E . install http://svn.cherrypy.org/tags/cherrypy-3.1.1/#egg=cherrypy

Either one of these methods give me a properly working CherryPy
install that allows me to do a:

from cherrypy.wsgiserver import CherryPyWSGIServer

However, checking out from a sub-directory does not work:

pip -E . install http://svn.cherrypy.org/tags/cherrypy-3.1.1/cherrypy/wsgiserver/#egg=cherrypy

because the setup.py file is not there.

Being able to do something like:

pip -E . install CherryPyWSGIServer

would be very helpful.

Thanks.

> fuman...@aminus.org

[Sylvain Hellegouarch]

Randy,

The only reason I'd see us splitting the server into a different package
would be because we split it into a "WSGI server library" which might or
might not make sense (the __init__.py is getting too large for my taste
so maybe it's worth it).

However we've always favoured one single package and pip isn't a strong
use case to split it for now.

I might argue one could fix pip so that it accepts svn resources which
don't have a setup.py

- Sylvain

Randy Syring a écrit :

[Randy Syring]

Sylvain,

I wasn't really suggesting that you split it out of the standard package.   Just make a second, server-only package.  As far as I can tell, the CherryPy WSGI server is just about *the best* python WSGI server (its certainly fastest in my testing).  Having to install all of cherrypy just to get the server is a lot of overhead to get just a single file.  Usage of the server might go up if people knew they could install the server without having to install the rest of CherryPy as well.

Futhermore, its not just a pip use case.  Making a seperate package would allow someone to be able to do:

easy_install -U CherryPyWSGIServer

Or something like that depending on what you named the package.

IMO, it would be very little work to package this at every release and if you do it the way I suggest, it wouldn't affect the normal CherryPy package at all.  If you wanted to do some kind of WSGI server library, that might be a good idea, but I don't think what I am asking for requires it.

Thanks for your consideration.

--------------------------------------
Randy Syring
RCS Computers & Web Solutions
502-644-4776
www.rcs-comp.com

"Whether, then, you eat or drink or
whatever you do, do all to the glory
of God." 1 Cor 10:31

[Sylvain Hellegouarch]

Randy Syring a écrit :

> Sylvain,
>
> I wasn't really suggesting that you split it out of the standard
> package. Just make a second, server-only package. As far as I can
> tell, the CherryPy WSGI server is just about *the best* python WSGI
> server (its certainly fastest in my testing). Having to install all
> of cherrypy just to get the server is a lot of overhead to get just a
> single file. Usage of the server might go up if people knew they
> could install the server without having to install the rest of
> CherryPy as well.
>
> Futhermore, its not just a pip use case. Making a seperate package
> would allow someone to be able to do:
>
> easy_install -U CherryPyWSGIServer
>
> Or something like that depending on what you named the package.
>
> IMO, it would be very little work to package this at every release and
> if you do it the way I suggest, it wouldn't affect the normal CherryPy
> package at all. If you wanted to do some kind of WSGI server library,
> that might be a good idea, but I don't think what I am asking for
> requires it.
>
> Thanks for your consideration.

I see. I guess your idea wouldn't actually break the current state
whilst providing an easier path for those who'd only want the WSGI
server itself. Sounds useful indeed.

Anyone else has a thought about it?

- Sylvain

[Christian Wyglendowski]

On Sat, Apr 11, 2009 at 4:21 AM, Sylvain Hellegouarch <s...@defuze.org> wrote:
>
> Randy Syring a écrit :

>> Thanks for your consideration.
>
> I see. I guess your idea wouldn't actually break the current state
> whilst providing an easier path for those who'd only want the WSGI
> server itself. Sounds useful indeed.
>
> Anyone else has a thought about it?

I think it sounds like a fine idea.

Christian
http://www.dowski.com

[Randy Syring]

On Apr 13, 8:44 am, Christian Wyglendowski <christ...@dowski.com>
wrote:

Great, I am glad this idea is gaining some ground. I have another
thought though. Should the package install with the same package
structure as cherrypy or would it have an alternate structure?

The reason I ask is because it would be preferable (IMO) to do:

from cherrypy.wsgiserver import CherryPyWSGIServer

as opposed to (naming is just for example purposes)

from cherrypyserver import CherryPyWSGIServer

Having the same import regardless of whether the full blown cherrypy
package was installed or just the server-only version seems better
from my perspective. However, I wonder if that might be an issue for
some packages which test for the existence of cherrypy. They might do
a simple:

import cherrypy

to test and if that works without an exception assume the whole
package is available when really only the server component is
available.

Just wondering how you thought you might implement it if you decide to
move forward with this idea.

Thank you once again for your consideration.

[Randy Syring]

Any further thoughts or movement on this idea?