Pycon and the development status of cherrypy

[Joel Rivera]

Hi everyone.

As a few may know the PyCon US is just right around the corner and it
might be a good time to discuss about the development status of
cherrypy, I'll be sprinting the four days at the pycon and I would like
to support cherrypy at the event.

This are the three possibilities that I'm thinking at the moment:

1. The next mayor release, I haven't found any formal document that
outline the design goals, but I remember that in the last pycon Robert
told me that he was thinking in separating the framework from the server
(cheroot) and it seems that magicbus it is also on the same track, but
I'm not sure about what is the state of that effort.

2. The current issues with CherryPy 3, there are a lot of issue in
bitbucket but some of them are very old that I really wonder if it worth
the effort to fix it, some of them are trivial, related to misleading
documentation or just extremely obscure. The help of some of the core
contributor in the obscure ones will be really needed.

3. Improve the documentation, more examples, tutorials and a cleanup to
tools.cherrypy.org.

What do you thing about the development status of cherrypy?, it is
stable it has good reputation but it might be a good idea to revitalize
a little more the project to attract new contributors.

Giving the nature of the pycon non-stop sprinting, the more specify
goals, the better the chance to be able to make something meaningful or
at least to attract new contributors after the event.

--
Rivera²

[Sylvain Hellegouarch]

Hi Joel,

Thanks a bunch for bringing CherryPy up at PyCon :)

All good points. Here's my feeling, not backed by any facts of course, CherryPy has a good image among those that use it, other people aren't aware about it or simply believe it's not a valid option any longer and prefer using Flask or Bottle. So, one thing of course would be to improve its image but I'm not sure pycon is the right place. Good PR is tough and, at this stage, I'm not sure the project as a vocal community anyway.

Nonetheless, the documentation is our Achille heal I believe. Flask has a great documentation. Not perfect but so much more useful than ours: http://flask.pocoo.org/docs/

Another example I love is the LearnYouSomeErlang book: http://learnyousomeerlang.com/content

I've been able to introduce CherryPy at work but I keep hearing about its incomplete documentation. I assume this would be the best strategy here. I doubt a sprint could rewrite a whole documentation but perhaps start the task? Note that I had setup CherryPy at ReadTheDocs: http://cherrypy.readthedocs.org/en/latest/

The accumulating bugs will become a problem indeed but at this point, unless we have a clearer picture of where CherryPy goes, I don't think there's much we should do. A sprint might help sorting bugs that should be fixed from others. 

 

Overall, I feel CherryPy is stable enough and has been for a while but it's a bit lifeless. Either we're happy with this as a community or we're not. Hopefully people will fight for it;)

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

[Tim Golden]

One key point in CherryPy's favour is that it's 3.x-ready and has been
for a while. (And has recent changes to its codebase to track recent
changes to Python). That's a real plus when the Flask stack
(Flask/Werkzeug/Jinja2) -- which I also use and like -- doesn't have a
clear 2->3 roadmap. Bottle, which I haven't used, appears to run on 3.x
as well.


TJG

[Nick Repole]

I'd add that on top of the documentation not being great, it's not especially easy to actually find people talking about CherryPy and getting input from others on questions or problems. The IRC room is generally pretty dead, and I'd venture to say a good number of CherryPy users aren't aware of this group's existence. I would very highly recommend putting a link to this group in the header of the CherryPy website as opposed to the footer, and referring to it as a group rather than a mailing list. Nothing huge, but I'd think it'd help a good bit.

[Anders Langworthy]

The glacial pace of development (in terms of having bugs acknowledged or
bugfixes or minor code improvements accepted into the tree, not in terms
of new releases or major features) is frustrating to people who might
otherwise put in more work to improve the codebase.

I sent in a doc patch a while back [1] and it basically went to whatever
hole patches go to die. It probably still applies cleanly, since 14
months later nobody else has improved the docs either. That patch was
trivial, but if I can't even get that put in then why should I bother
trying to patch up a fix for something more substantial? I'm probably
not the only one who feels that way -- certainly some just glance at the
age of the latest changeset, notice the dozens of aging and still
unassigned bugs, and don't bother.

This is just my unqualified opinion, and don't get me wrong -- I use
cherrypy every single day and think it is fabulous tool...but I do think
part of the "lifeless" feel of the community is due to lack of feedback
or response to would-be contributors and is a problem that could be
corrected with some effort.

[1]:
https://groups.google.com/forum/?fromgroups=#!topic/cherrypy-devel/5dRk17JDyX8

--
Anders Langworthy

[Sylvain Hellegouarch]

Hey Anders,

I cannot only speak for me but my involvment has always been more around helping the community more than the code itself but I think I've felt like I need to move on for a while now. I also use it every single day and I'm always happy to help newbies whenever I can but I'll admit I don't have the energy nor the will for bugs or new features.

Perhaps old-timers like me (I've been around since 2003) should make it loud and clear it's time for someone else to take over or the project will be good to a peaceful retirement. But then again, I am not the main actor here, Robert is :)

I think CherryPy has more to say if we follow the ideas behind splitting packages but I have no energy for it (though I'll be super happy to use it ;)).

[Sylvain Hellegouarch]

I cannot only speak for me 

Yeah for clarity.

[Joel Rivera]

On Tue, 2013-02-26 at 17:26 +0100, Sylvain Hellegouarch wrote:
>
> Perhaps old-timers like me (I've been around since 2003) should make
> it loud and clear it's time for someone else to take over or the
> project will be good to a peaceful retirement. But then again, I am
> not the main actor here, Robert is :)
>

That is the impression that I have, which is natural, everybody gets
tired o bored on working on the same stuff, not that it doesn't like it
anymore, it is just a more basic thing of the human nature or maybe new
commitments in the private life, but making it public it is so much
beneficial to the project, there are people who happily devote their
time on for example keep an eye to the pull requests and issues. Maybe a
model of BDFL might be a good idea.

Personally I consider one of the very new breed, I have been using
cherrypy the last three year and python since 2006 and in the last year
I have embrace the philosophy that the best documentation is the code
itself, so that the reason that I don't been let down by the
documentation. But probably the average python programmer wouldn't think
that way and turn around to flask or bottle.

I think that it is better to be moving and changing than dying and being
forgotten.

Last year Robert was on the PyCon, I'm not sure if he will be attending
this year.

--
Rivera²

[Tim Roberts]

Joel Rivera wrote:
> What do you thing about the development status of cherrypy?, it is
> stable it has good reputation but it might be a good idea to revitalize
> a little more the project to attract new contributors.

You have touched on one of my hot buttons here. Please excuse any ranting.

You have expressed an attitude here that I find quite a bit in open
source projects -- that a stable project is a dying project -- and I
find it utterly baffling. When one goes to create a product, one does
so to have it serve some purpose. Once the product has reached a point
where it fulfills that purpose, the product is DONE. Why do we need to
keep churning? When one feels the need to keep adding more and more
stuff, one ends up with Microsoft disease, where each new release simply
adds a thousand confusing and memory-cramming features that no one will
ever use.

CherryPy does what it needs to do, and it does it extremely well.
(Actually, in my opinion, CherryPy 2.x also did what it needed to do,
but I admit that the reorganization in CherryPy 3 added some cool new toys.)

But what's left? HTTP has not changed significantly. The web biosphere
has not changed significantly. HTML 5 does not have a significant
impact on the server. CherryPy already handles AJAX and WebSockets.
What holes are left to patch?

I know some of you will accuse me of trying to close the patent office
because "everything that can be invented has been invented", and you may
be right. On the other hand, if you've read any of the so-called
"inventions" that have been patented in the last 10 years...

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Sylvain Hellegouarch]

I think you're right and yet, it seems only fair that, considering the number of bugs that are being reported and left untouched, the community wonders what gives. CherryPy does its thing really well (seriously I always come back to it), it doesn't mean it hasn't space for more or better. CherryPy is indeed alive and well and maybe that's the main word the community should carry out. 

[Robert Brewer]

I'll be at PyCon 2013, but as pointed out, other interests both commercial and private have sapped the time I can contribute to CherryPy. I have definite ideas about where the development of CherryPy 4.x should go from here, but haven't the hours to either write it or coordinate the work from others. If anyone would like to sprint on CherryPy 3.x or even 4.x, I can make myself available to advise, but I'll be spending the first 3 days of sprints at the PyData mini-conf (giving a talk and listening to many others). Any of you should feel free to catch me over the conference weekend (we could even try setting up a BoF) or later in the sprints to chat about any aspect of CherryPy (except auth or sessions, not worth my time--wink).

I'll be spending my remaining time sprinting on our new startup with other coworkers in town. But if other folks want to sprint on CherryPy, I'm all for it. You could do a doc sprint, but those never seem to get "done enough". I'd recommend sprinting on cheroot, which doesn't need much design work but could use lots of tests (and profiling and benchmarks), docs, and marketing, and possibly a shim in CherryPy 3.x to use it (only CP 4.x uses it at the moment). If someone gave a lightning talk on cheroot, you might get some sprinters from the other communities to join in if they can see the benfit of a standalone Python HTTP/WSGI server that doesn't bring any framework with it.


Robert Brewer
fuma...@aminus.org

[Joel Rivera]

On Tue, 2013-02-26 at 10:00 -0800, Tim Roberts wrote:
> But what's left? HTTP has not changed significantly. The web
> biosphere
> has not changed significantly. HTML 5 does not have a significant
> impact on the server. CherryPy already handles AJAX and WebSockets.
> What holes are left to patch?
>
>

I agree with the idea that CherryPy already does what it was meant to
be, but this is just from the perspective of the code, not the whole
project.

The laking of good documentation and active community it is very
important. It's a little naive to think that the code is perfect, I
personally think that there is no such thing, even if we focus only in
the bugs there are bug waiting to be spotted and the greater the
community the better the chance to spot those.

I think that being-self critical about the current issues of the project
is a good thing and to consider the feedback from the community doesn't
mean that is going to be a mess of ideas, if the feedback is received
with an open mind and responded with good arguments.

In my perspective a project is over, when is completely fucktup and need
to be rewritten to make any substantial change or the user base is so
small that eventually any one of the members are just going to move to
something more active, and for the first case is not a big issue if you
have an active community.

But in the end, that's just my point of view.
--
Rivera²

[Anders Langworthy]

Hi Sylvain,

I consider the two best documentation sources for CherryPy to be the
source itself and your mock Twiseless app. The few times I've had
questions, you've been quick to respond. Thanks, from the community and
from me personally.

I try to answer questions on this list when I know the answer (or when
it is clear that nobody more competent is around to weigh in), and I
would love to help fix bugs and improve the docs. There are plenty of
others out there in a similar boat, and I think if the project is
willing to accept the help it will find plenty available. In order to
utilize this though there needs to be receptive people at the helm to
give feedback and eventually bring acceptable patches into the tree. I
don't think that this is happening well enough right now. I think
acknowledging this and talking openly about ways to fix it would go a
long way towards making sure that CherryPy remains a great tool for
future users.

Cheers,
Anders

[Joel Rivera]

On Tue, 2013-02-26 at 10:34 -0800, Robert Brewer wrote:
>
> I'll be at PyCon 2013, but as pointed out, other interests both
> commercial and private have sapped the time I can contribute to
> CherryPy. I have definite ideas about where the development of
> CherryPy 4.x should go from here, but haven't the hours to either
> write it or coordinate the work from others. If anyone would like to
> sprint on CherryPy 3.x or even 4.x, I can make myself available to
> advise, but I'll be spending the first 3 days of sprints at the PyData
> mini-conf (giving a talk and listening to many others). Any of you
> should feel free to catch me over the conference weekend (we could
> even try setting up a BoF) or later in the sprints to chat about any
> aspect of CherryPy (except auth or sessions, not worth my time--wink).
>
> I'll be spending my remaining time sprinting on our new startup with
> other coworkers in town. But if other folks want to sprint on
> CherryPy, I'm all for it. You could do a doc sprint, but those never
> seem to get "done enough". I'd recommend sprinting on cheroot, which
> doesn't need much design work but could use lots of tests (and
> profiling and benchmarks), docs, and marketing, and possibly a shim in
> CherryPy 3.x to use it (only CP 4.x uses it at the moment). If someone
> gave a lightning talk on cheroot, you might get some sprinters from
> the other communities to join in if they can see the benfit of a
> standalone Python HTTP/WSGI server that doesn't bring any framework
> with it.
>
>

Well that's good and bad news, so I'll catch you in between
talks/sprints, I will be more interested in your thoughts about cherrypy
4, as for the idea to use cheroot to gain support, I'm not really sure,
because I haven't really use cheroot, but probably I'll experiment with
it this weeks substituting a paster server that I'm using with pyramid
and maybe make a few benchmarks, you can support any wsgi server without
the obvious comparisons of the competitors and the different benchmarks.

And as a side note, it would be nice if the person who manage the
cherrypy account in twitter makes a call to arms mentioning the pycon
account and the sprints, given the experience of previous pycon, twitter
is a big deal in the conference.

--
Rivera²

[Jon]

> On Tue, 2013-02-26 at 10:34 -0800, Robert Brewer wrote:
> >
> > I'll be at PyCon 2013, but as pointed out, other interests both
> > commercial and private have sapped the time I can contribute to
> > CherryPy. I have definite ideas about where the development of
> > CherryPy 4.x should go from here, but haven't the hours to either
> > write it or coordinate the work from others.

I gauge a project's "activeness" based primarily upon timely triage of bugs/patch submissions. ML support, documentation, new capabilities, and tech evangelism are important, but secondary.

Given the comments, is there truly a bug/patch bottleneck? Does it harm CherryPy?

If yes, what (or who) is the primary cause? If it's Robert's current paucity of time, perhaps it's time to transition the project lead baton.

A transition can be handled gracefully. For example, advertise for a new project lead on the ML, web site, twitter, etc with something like

"On XX-ABC-2013 I will stepping down as CherryPy's project lead and
primary maintainer. If you value CherryPy, are passionate about its
continued maintenance/development, and are able to commit the time
required of a project lead, I'd like to hear from you."

and see who responds. That said, if a talented CherryPy hacker thought the bottleneck was a real show-stopper, he/she would likely have already raised the issue.

But who knows, open the gates and see where the discussion leads.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums

[Eric Larson]

Anders Langworthy writes:

> I consider the two best documentation sources for CherryPy to be the
> source itself and your mock Twiseless app.

Even though I snipped most of the conversation so far, this bit
regarding Sylvain's Twiseless app and the source speak volumes for the
future of CherryPy for myself.

The docs are definitely in need of some love, but I believe that doesn't
really speak to the future of CherryPy. No, what CherryPy needs is a
framework! Sort of...

I always feel like CherryPy is the tool that can cut your face off. It
is efficient, powerful, and flexible, yet, using it means you have to
know what you're doing. Once you do know what you're doing, the world
becomes a plethora of powerful tools, encapsulating orthogonal concerns
and plugins managing the nitty gritty details orchestrating your
databases and pools of connections. It is just that getting there is a
tough process.

As others have mentioned, I'd propose is that CherryPy 4.x focus on
separating the concerns.

- Cheroot: The CherryPy WSGI server
- MagicBus: A CherryPy bus to make happily managed proceses
- CherryPy: A raw WSGI library to build frameworks
- *Alamode: A minimalist framework that exposes best practices for data
driven applications

Alamode is a new idea that takes aspects of Twiseless and other best
practices we've found and codifies them into an easy to use
framework. The goal is not to do things like scaffolding or include
crazy widgets, but we would promote and provide tooling for some basic
aspects such as:

- templating
- routing / dispatch
- setting up pools / databases / supporting services
- tools / application plugins
- testing
- async vs. threads vs. processes

This seems like a huge task, but it doesn't seem *that* crazy. The goal
is not to create the perfect framework, but rather provide *a* framework
that describes the means of peeling the layers off to reveal the "raw"
CherryPy framework.

In order to provide an experience different from the default CherryPy,
it would make sense to try and create something similar to Flask's
API. If folks don't like Flask's API, that is OK. Alamode is there to
facilitate people easing into CherryPy and provide a direction for
polishing the harsher aspects of CherryPy as a framework. It would
build on the stable shoulders of the current CherryPy tools. No matter
what the the framework endorses, the goal is to develop CherryPy's
framework and tools.

A new framework seems like it could be fun, but I don't want to take
away from the excitement hiding within cheroot and magicbus. Cheroot
could do well to find a way to adopt different processing models (async
vs. processes vs. threads). Applications often end up doing crazy things
in order to support different models. Imagine being able to configure
something like this:

config = {
# Support a model like flup where we prefork a pool of 8
# processes, each using a pool of 30 threads.
'/': {
'server.serving.model': 'prefork',
'server.serving.threads': 30,
'server.serving.processes': 8,
},

# Use greenlets to provide an async model. We also would provide a
# worker API to handoff non-async friendly tasks to a worker. Here
# my example could use a Celery worker.
'/chat': {
'server.serving.model': 'async',
'server.serving.workers': MyCeleryWorker(),
},

# Yet another model where each request is placed on some sort of
# worker queue, handled by a worker. This could be something like
# Mongrel2's design or something else completely.
'/crunch': {
'server.serving.model': 'worker',
'server.serving.handler': MyZMQWorker,
}
}

# We added a plugin for starting up a pool of workers to listen on a
# zmq pub/sub socket for our /crunch endpoint.
cherrypy.engine.zmqworkers = ZMQWorkerPool(20)

Cheroot seems like it could be refactored to have an extremely pluggable
API to support this kind of model. Hopefully we could have the best of
all worlds with this kind of system.

The magicbus could also gain some more power by providing some
coordination plugins. Small plugins like heartbeats and distributed
event passing could make for some cool features to help answer the
question of orchestrating processes for scale.

Lastly, CherryPy as a library and framework would benefit from all the
above. Tools, plugins and the framework could all have to improve in
their APIs in order to support the new features. Even if the docs are
the only place this happens, we'd have a whole new array of use cases,
blog posts, mailing list conversations and examples to draw from.

If you've read this ramble this far, thanks! I use CherryPy every day at
work and see others avoiding it in favor of tools like Flask. It makes
no sense to me until I sit in their shoes. They see CherryPy as boring
and not worth the investment. What they don't understand is CherryPy has
so many great design elements that make the future of the web (data
driven RESTful services with a fancy HTML / mobile interface on top)
easy to write. I wrote CherryFlask[1] to convince myself that CherryPy
has a future in this regard and once again was proven that it is a well
designed and powerful framework.

Seeing as I'm not a huge contributor to CherryPy, please do not feel I'm
demanding that we do this proposal. I'm happy to head up organizing the
framework aspects assuming others are willing to provide their best
practices. I already started writing an Alamode library based on some
best practices we use for dispatching at work. I have a few ideas for a
consistent configuration model and testing as well. There is also my
CherryFlask experiment that could be expanded upon.

No matter what we do moving forward it would be worthwhile to write up
some sort of a design document and/or mission statement we can loosely
agree upon to help find direction. Again, I'd be happy to act as a
secretary in this regard and keep a spec/design document up to date.

Thanks again for reading my rambling, and as always, thanks for
CherryPy!

Best,

Eric

[Joel Rivera]

> As others have mentioned, I'd propose is that CherryPy 4.x focus on
> separating the concerns.
>
> - Cheroot: The CherryPy WSGI server
> - MagicBus: A CherryPy bus to make happily managed proceses
> - CherryPy: A raw WSGI library to build frameworks
> - *Alamode: A minimalist framework that exposes best practices for data
> driven applications
>
> Alamode is a new idea that takes aspects of Twiseless and other best
> practices we've found and codifies them into an easy to use
> framework. The goal is not to do things like scaffolding or include
> crazy widgets, but we would promote and provide tooling for some basic
> aspects such as:
>
> - templating
> - routing / dispatch
> - setting up pools / databases / supporting services
> - tools / application plugins
> - testing
> - async vs. threads vs. processes
>
> This seems like a huge task, but it doesn't seem *that* crazy. The goal
> is not to create the perfect framework, but rather provide *a* framework
> that describes the means of peeling the layers off to reveal the "raw"
> CherryPy framework.

I totally agree with you points Eric and I'll happily devote a good
amount of my time to make this real. I will like to see what Robert
thinks about this proposal.
--
Rivera²

[Sylvain Hellegouarch]

Hi Eric,

Clearly CherryPy needs a little help to make people more aware of its powerful features. However, I'm a little wary that adding a new project and more code isn't going to be easy since we can't cope with what we have now.

I have a feeling that better documentation and well-maintained recipes could go a long way. Not to dismiss your idea but I'm careful not to undertake something we can't handle.

[Eric Larson]

I totally agree, so let me contextualize the reason for a new,
complimentary project. Then we can feel free to dismiss it ;)

In terms of recipies and docs, Alamode would simply be an installable
and codified version of our best practices. There can be new docs that
reiterate details in the CherryPy docs. Users could install the recipes
and use them immediately vs. copying code from somewhere else and having
to remember the best practice. This speaks to those who "just want to
get things done."

For existing users, it offers a new means of thinking about the
project. It is much easier to contribute a handy tool or plugin than it
is to reproduce a user's issue and try to fix it. The extra traffic and
discussion over new code will only help increase the review of old docs
and code.

Furthermore, it provides a context for our existing code and docs. Many
of us are comfortable with CherryPy and have learned to jump into the
source code. Codifying our recipes and best practices into a project
like Alamode gives us a new perspective. It could move us out of our
comfort zone, which would help ramp up interest in giving the CherryPy
docs and code the love it needs.

Finally, the goal is to create new avenues for learning about CherryPy
that might let other users "get it". A new project might feel new and
fresh to an onlooker, making the investment in learning it
exciting. When a new project is ready, we would communicate that by
using Alamode, you build on the legendary stability of CherryPy, making
it even more enticing to learn and contribute to.

In my history as a developer there have been many entry points to
learning new technologies. IRC, blogs, tutorials, docs and screencasts
have all been critical in helping me discover different tools. The idea
for Alamode is to present more roadways leading to CherryPy while
presenting a specific use case for those already wanting to contribute.

If we give it a try and it fails, no big deal. That is a whole
centralized set of docs, mailing list discussions and code that we can
integrate back into CherryPy.

Hopefully this clarifies why starting a new, complimentary project could
be helpful. I already have a repo on my computer for Alamode that I
started a long time ago, so if folks want to send me any ideas, code
snippets, etc. I'm happy to integrate them and we can see what it could
actually look like.


Eric

[Joel Rivera]

On Wed, 2013-02-27 at 11:53 -0600, Eric Larson wrote:
> Hopefully this clarifies why starting a new, complimentary project
> could
> be helpful. I already have a repo on my computer for Alamode that I
> started a long time ago, so if folks want to send me any ideas, code
> snippets, etc. I'm happy to integrate them and we can see what it
> could
> actually look like.
>
>

I think that blueberrypy [1] is trying to archive something similar,
have you consider to host the project a public repository?.

[1]: https://bitbucket.org/wyuenho/blueberrypy

--
Rivera²

[Joseph S. Tate]

On Wed, Feb 27, 2013 at 11:08 AM, Sylvain Hellegouarch <s...@defuze.org> wrote:

Clearly CherryPy needs a little help to make people more aware of its powerful features. However, I'm a little wary that adding a new project and more code isn't going to be easy since we can't cope with what we have now.

I have a feeling that better documentation and well-maintained recipes could go a long way. Not to dismiss your idea but I'm careful not to undertake something we can't handle.

 

It's definitely good to see discussion about how to liven development up.  I know that for several patch queues, I haven't been able to make intelligent evaluations, so I haven't tried.  Other queues have probably just slipped through the cracks.  I'd like to publicly thank Jason Coombs for doing most of what has been done over the past few months while Bob (mostly) and I (more recently) have been busy with our day job (which we're hiring for).

As one of the (mostly quiet) devs.  I'd like to see more devs involved in the day to day.  But for that we'd need to get to know potential contributors better.  Reviewing and submitting patches is the best way outside of attending a sprint to be visible to devs.  I'll be with Robert at PyData during part of the sprints, so I won't be much help, but I'll be around for PyCon and here and there to help out where I can.

If you're seeing long delays on your patches getting accepted, reminder bumps may be helpful to get our attention, or nagging in the IRC channel.  If some of the heavier CherryPy users can help validate patches to be accepted, that makes our job of accepting patch queues easier.  Having patches that apply against the default (dev) branch are also easier to swallow when they're far reaching in effect.

I'd be glad to see a framework project spring up, but unless it scratched my particular itches (at least 80%), I likely wouldn't be very involved.  That's the primary problem I see with demo apps, examples in documentation, and frameworks in general:  To stay fresh, they have to remain useful to the original developers (as a production app), or see a steady stream of new development talent to keep them current.  TurboGears 1.x was a real driver for CherryPy popularity 5-6 years ago, but when it moved away from CherryPy, CP's popularity waned.

All that said, I think a listing of "Best Practice" tools (both in CherryPy and general framework terms) and strategies would be a great thing, and may be the first step to getting a useful (to other devs, even core devs) framework together.  I'd gladly help get that list going, and would gladly contribute my own personal cp tools and libraries that I've built up over the years.

I think another sprint task that would be useful would be documenting how to run unit tests against your CP app, both in a unit test scenario and using the helper.CPWebCase class.  We should probably do a bit of refactoring of the test suite so that it's easier to understand.  If I have some spare time during sprints, I'll see if I can work on that.

--

Joseph Tate

[Eric Larson]

I had planned on releasing it as soon as it had a bit more focus. It is
really not much more than some docs built from some blogs of mine along
with the code.

My problem was that I already knew CherryPy relatively well and had
projects to maintain. The result being I had little incentive to create
different pieces. This is partially why I think an Alamode project could
work.

I had not seen blueberrypy, but yes, that seems like a great
example. I'll look at it more closely and see if I can find a good way
to merge the work. Thanks for pointing it out!

Eric

[Eric Larson]

Joel Rivera writes:

> On Wed, 2013-02-27 at 11:53 -0600, Eric Larson wrote:
>> Hopefully this clarifies why starting a new, complimentary project
>> could
>> be helpful. I already have a repo on my computer for Alamode that I
>> started a long time ago, so if folks want to send me any ideas, code
>> snippets, etc. I'm happy to integrate them and we can see what it
>> could
>> actually look like.
>>
>>
> I think that blueberrypy [1] is trying to archive something similar,
> have you consider to host the project a public repository?.
>

Just wanted to follow up on this. I got a sec to organize some code I
had for alamode and put it up:

https://bitbucket.org/elarson/alamode

If anyone has snippets or doc suggestions, even if they are not fully
fleshed out, feel free to send them along.

Eric

[Zoltan Giber]

Hi,

As a self-thought designer becoming a self-thought developer I seldom write to programming groups, and when I do it's mostly a question :) .. however, please allow me to raise my voice here and +1 for improving the documentation.

Here is why:

As many others, I like python a lot. I'm developing a web based application, and I did some research about the best tools for it. I don't think that I need to prove anything, but cherrypy is one of the best performing servers, and the framework seems to be very lean too. I dropped the idea for Pyramid and Django for their bloatedness.

So my choices:
Google App Engine or Cherrypy.

Google App Engine is great, with very enviable documentation. I learned a lot from tinkering with it, without GAE, I probably wouldn't understand a word of the Cherrypy docs. But with GAE I'm charged for every tiny DB transaction... simple things as implementing my own db backed sessions, and user management already exhaust quotes quickly.

With Cherrypy on the other hand, I'm struggling to find out how things work.. once I get it, it makes sense, but for most things there are no examples.. nada.. detailed descriptions about some methods, yes, but nothing about how to use them. I admit I'm not a seasoned programmer, but  it was easier for me to write my own in-memory session management then finding out how to use the Cherrypy solution. A simple few liner working example would have made a huge huge difference.. Sorry guys I don't want to complain, and you made a wonderful job with cherrypy, but I can tell you, with a good documentation (a'la GAE), the user base could grow very fast instead of the decline. If I can contribute something with my limited coding expertise feel free to let me know. 
z.

[Joel Rivera]

> With Cherrypy on the other hand, I'm struggling to find out how
> things work.. once I get it, it makes sense, but for most things
> there are no examples.. nada.. detailed descriptions about some
> methods, yes, but nothing about how to use them. I admit I'm not a
> seasoned programmer, but it was easier for me to write my own
> in-memory session management then finding out how to use the Cherrypy
> solution. A simple few liner working example would have made a huge
> huge difference.. Sorry guys I don't want to complain, and you made a
> wonderful job with cherrypy, but I can tell you, with a good
> documentation (a'la GAE), the user base could grow very fast instead
> of the decline. If I can contribute something with my limited coding
> expertise feel free to let me know. z.
>

Agree on this necessity, in fact I'm convinced that this is the issue
number one that I would like to focus on the PyCon and as a secondary
goal take a closer look and possibly hack some code to the "scaffolding"
frameworks on top of cherrypy of alamode [1] and blueberrypy [2], and
leave cherrypy 4 to just occasional conversation that I hopefully can
have with Robert (if I'm able to catch him between conferences).

As a way to support a documentation effort regardless the level of
expertise with cherrypy and the physical location during the sprints I
can think on this categories:

1. Beginner:
Give the opinion on what would be good to have or what is not
obvious to the newcomer, a fresh pair of eyes can witness a
lot of overlook to the local cherrypy community, imagine the
hypothetical situation on which 95% percent of the questions that
this list received could be resolved just referencing a
particular place of the documentation and make sure that place is
clear on what is the answer not just because is hidden between
lines or in a code snipped. Also the beginners can be the "QA" of
the documents that are generated.
2. Intermediate:
Analyze your current implemented patterns on your own cherrypy
applications and propose/write a sample document or tutorial. If
the pattern is flexible and have a general purpose that could
possibly be integrated to alamode/blueberrypy.
3. Advanced.
Document the internals in a friendlier manner to have a
clear distinction between the levels of integration plugins,
tools, dispatchers, servers, request flow, web sockets, error
handling, the notion of "cherrypy application" and the multiple
ways to configure the same application at different points, among
others, most of the current documentation is focused on this, but
that can be improved. Do peer reviews to the Intermediate
proposals and of course all the proposed activities to the
Intermediates also applies to this level of expertise.

Any opinions about those three point are very welcomed.

The PyCon sprints are going to be held from March 18 to 21 (and
probably the night of the 17), I would love to see remote involvement
on the IRC channel and support spreading the word on twitter or any
other social network/mail list. The sprint does not mark the ONLY dates
that I am (we are [hopefully]) going to pursuit this effort, but rather
the "official" start and with some of luck attract
newcomers/contributors given the temporal euphoria around python on
those days.


[1]: https://bitbucket.org/elarson/alamode
[2]: https://bitbucket.org/wyuenho/blueberrypy
--
Rivera²

[Zoltan Giber]

Hi, I've started to put together some thoughts about my experience with cherrypy docs.. It's not a critique rather some lines about how i could learn better from the docs. It's mostly around the tutorial idea. feel free to edit/comment whatever..

https://docs.google.com/document/d/1sHJJxFTgT2-2VXyWIy-L4d-JwaN-BYwLFbrGXDVL6YU/edit?usp=sharing

thanks

z

[Gerold Penz]

Am 2013-03-08 00:53, schrieb Zoltan Giber:
> I can tell you, with a good documentation (a'la GAE), the user base
> could grow very fast instead of the decline.

+1

--
Gerold Penz - http://halvar.at
Wissen hat eine wunderbare Eigenschaft:
Es verdoppelt sich, wenn man es teilt.

[Michiel Overtoom]

On Mar 10, 2013, at 02:08, Zoltan Giber wrote:

> [...] some lines about how i could learn better from the docs. [...] Feel free to edit/comment whatever.

Excellent idea. I'd like to add two things:

1) Explain when and why to choose CherryPy instead of Flask/Django/Tornado etc... Highlight some things that CherryPy does better/more modular/more pythonic than other frameworks. Nowadays if you dare to suggest anything other than Flask on #python you get castigated. It's either Flask (lightweight requirements) or Django (heavyweight requirements) there.

In short, I think this would help acceptance of CherryPy:

- a page which compares CherryPy features to other popular webframeworks;
- enumerates the specifics which make CherryPy different than the rest;
- explains in which cases CherryPy is the better choice over another framework.


2) Clean up the 'CherryPy Success Stories'. It's more a list of 'Sad Stories' at the moment. Many of the sites listed simply don't exist anymore, have been gobbled up by stupid SEO spam portals, or have switched to WordPress or Django.

I did some research into this and wrote up an analysis:

http://www.michielovertoom.com/articles/cherrypy-success-stories/

I surveyed 19 of the alleged 'CherryPy success sites' but could only verify 2 or so still exist and probably are using CherryPy.

Greetings,

--
"If you don't know, the thing to do is not to get scared, but to learn." - Ayn Rand

[Justin Olmanson]

Culling content from the archives of this listserv could form the initial text for many of the suggested sections...

And/or

this list might help build up the docs by answering a prompt or weighing in on an initial topic response. people could send their takes on the issue, synthesize what others have said, and add it to the docs (doing say one topic/question per week would keep it from bogging down the list, and doing it together would help it fit in the established interactional grammar of people's work day)

In this way we get there by accrual and via a leveraging of existing materials (organized, updated, and repackaged)

-Justin

Sent from a mobile device

> --
> You received this message because you are subscribed to the Google Groups "cherrypy-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cherrypy-user...@googlegroups.com.
> To post to this group, send email to cherryp...@googlegroups.com.
> Visit this group at http://groups.google.com/group/cherrypy-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Sylvain Hellegouarch]

On Sun, Mar 10, 2013 at 11:51 AM, Michiel Overtoom <mot...@xs4all.nl> wrote:

On Mar 10, 2013, at 02:08, Zoltan Giber wrote:

> [...] some lines about how i could learn better from the docs. [...] Feel free to edit/comment whatever.

Excellent idea. I'd like to add two things:

1) Explain when and why to choose CherryPy instead of Flask/Django/Tornado etc... Highlight some things that CherryPy does better/more modular/more pythonic than other frameworks. Nowadays if you dare to suggest anything other than Flask on #python you get castigated. It's either Flask (lightweight requirements) or Django (heavyweight requirements) there.

In short, I think this would help acceptance of CherryPy:

  - a page which compares CherryPy features to other popular webframeworks;
  - enumerates the specifics which make CherryPy different than the rest;
  - explains in which cases CherryPy is the better choice over another framework.

Comparison are handy if they stay objective. Something like this: http://docs.basho.com/riak/latest/references/appendices/comparisons/

 

2) Clean up the 'CherryPy Success Stories'. It's more a list of 'Sad Stories' at the moment. Many of the sites listed simply don't exist anymore, have been gobbled up by stupid SEO spam portals, or have switched to WordPress or Django.

I did some research into this and wrote up an analysis:

    http://www.michielovertoom.com/articles/cherrypy-success-stories/

I surveyed 19 of the alleged 'CherryPy success sites' but could only verify 2 or so still exist and probably are using CherryPy.

Greetings,

Indeed the success stories page is indeed rather sad right now. It'd need some purging.

Talking about CherryPy being used out there, maybe ask the guys at netflix:  http://www.reddit.com/r/Python/comments/1a35h8/python_at_netflix/ 

[Nick Repole]

I think a big part of the problem isn't that the simple examples don't exist, it's that they're not as in your face and easily accessible as they could/should be. Take the sessions page for example, there are a few snippets of code but nothing resembling a fully functional example. The cookie page on the other hand I think gets it right, and if more pages had similar extended examples at that level I think some concepts would be a lot easier to pick up quickly.

There's a level of hand holding there, and sure it'd be nice if that wasn't necessary, but if you want to grow a user base I think it is at times.

-Nick

[Joel Rivera]

Something particular to CherryPy is that is mostly used in internal
sites, I have just read that Netflix uses CherryPy [1], I have
personally build the logistics manager for a local company [2], the
email event tracker for another [3] and for fun I rewrote my
blog [4] [5], which is "connected" from Emacs [6], but I haven't update
to the official domain (blog.joel.mx) and do a serious
blogging. A quick look to the python job board yield this [7] REST
services.

The thing with CherryPy is that most of the time is used for
custom backend applications, where flexibility, stability and low
dependency overhead are much more appreciated, instead of the typical
public web application which is connected to X different social networks
and you just need to plug a bunch of modules to bring the
functionality.

That doesn't mean that CherryPy is not suitable for the
job, but a mixture of poor documented patterns and no publicly defined
standard to share CherryPy applications has isolated CherryPy to his
niche given the current contenders. I can almost be sure that a lot of
people has left CherryPy only because the new frameworks are more
trendy and has more active communities.

Probably if I was totally new to python and want to make a website will
pickup django/flask/bottle (pyramid is a little hard to the newbie
in my opinion) and apparently the recommendation if you want something
more WSGI is go to Werkzeug [8].

Getting back into the documentation improvements, those a good
recommendations and I invite anyone interested in actively
participate on the sprint even add you name and nick on IRC to the
pycon sprints page [9].


[1] http://techblog.netflix.com/2013/03/python-at-netflix.html
[2] http://www.arrive.mx/
[3] https://www.ensitech.com/
[4] http://tests.joel.mx/
[5] https://github.com/cyraxjoe/maki
[6] https://github.com/cyraxjoe/emaki
[7] http://www.python.org/community/jobs/#crunch-io-san-francisco-ca-usa
[8] http://werkzeug.pocoo.org/
[9] https://us.pycon.org/2013/community/sprints/projects/#cherrypy


--
Rivera²

[Sylvain Hellegouarch]

To me the documentation is the most important aspect but I also agree that having a polished and modern demo/skeleton app would be a big plus.

Something along:  https://github.com/albertogg/flask-bootstrap

[Julien Cigar]

what is missing also is plugins/tools for well-known libs like SQLAlchemy, Chameleon, Jinja, etc
I writed one for SQLAlchemy and Chameleon if it can help https://github.com/silenius/cputils

http://twitter.com/lawouach --

[Sylvain Hellegouarch]

Hi Julien,

On Mon, Mar 11, 2013 at 10:20 PM, Julien Cigar <jci...@ulb.ac.be> wrote:

what is missing also is plugins/tools for well-known libs like SQLAlchemy, Chameleon, Jinja, etc
I writed one for SQLAlchemy and Chameleon if it can help https://github.com/silenius/cputils

There are these ones:

https://bitbucket.org/Lawouach/cherrypy-recipes/src

[Gerold Penz]

Am 2013-03-10 11:51, schrieb Michiel Overtoom:
> 2) Clean up the 'CherryPy Success Stories'. It's more a list of 'Sad Stories' at the moment.

Hello!

A drop in the ocean: All these onlineshops are made with CherryPy and
run each as standalone daemon behind Pound as reverse proxy.

http://www.skischoolshop.com/

One problem is, that many sites we made, are only available behind a
login site. Example: https://dev-desk.skischoolshop.com/
But they are all made with CherryPy.

Regards,
Gerold
:-)