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.
Randy Syring wrote: > 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.
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?
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,
> Randy Syring wrote:
> > 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.
> 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?
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
> 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,
> On Mar 31, 1:42 am, "Robert Brewer" <fuman...@aminus.org> wrote:
>> Randy Syring wrote:
>>> 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.
>> 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?
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
On Fri, Apr 10, 2009 at 7:35 PM, Sylvain Hellegouarch <s...@defuze.org> wrote:
> 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 :
> > 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,
> > On Mar 31, 1:42 am, "Robert Brewer" <fuman...@aminus.org> wrote:
> >> Randy Syring wrote:
> >>> 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.
> >> 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?
> 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.
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.
On Apr 13, 8:44 am, Christian Wyglendowski <christ...@dowski.com>
wrote:
> 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.
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.
> On Apr 13, 8:44 am, Christian Wyglendowski <christ...@dowski.com>
> wrote:
> > 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.
> 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.
|
