CherryPy's future
985 views
Skip to first unread message
Sylvain Hellegouarch
Dec 30, 2014, 9:44:34 AM12/30/14
to cherryp...@googlegroups.com
Hi folks,
I hope everyone has a good holiday season. Anyway, I was going through CherryPy's issue tracker and gosh... we still have plenty. Honestly, I'm not sure what to do at this stage.
It seems there are way too many reported issues and too few of us to actually do anything concrete to reduce the workload. So what now?
I'm confident CherryPy has its place in web development ecosystem. Sure it's not the fastest, nor it is the most trendy web app framework these days. But it is simple, flexible and reliable. Many people favour those over raw speed or bare capacity. What this means is that CherryPy shouldn't die. We're not a Apache project yet ;-)
With that being said, there are various tracks we should pursue to really improve the situation. Offge the top of my head:
* Define a sensible and achievable roadmap for the project
* Identify people willing to actively work on it (and provide them with permissions over the project)
* Clean up our delivery workflow and schedule. Fix our delivered packages to avoid the issues we had with platform-dependant distributions
* Go through our bug database, sort them into categories and prioritize them
* Continue on working on the documentation
Overall, nothing new here. Inject some life into the project!
Roadmap
=======
As it stands, CherryPy works great and has had a stable API for many years. I'm not sure people would appreciate if we started breaking that API altogether. Or they'd probably move to greener pastures like Flask or Tornado (which would make sense considering how ubiquitous these frameworks have become).
So, the point is to be realist about where CherryPy stands and continue into that direction. As always, do one thing well rather than many poorly. For this reason, I think our best approach is to actually make CherryPy more and more lean and clean.
Clean the code first because, honestly it's a bit of a mess (blame HTTP, WSGI and Python 2vs3 corner cases) as is our package layout. Indeed, let's give up the whole _cp* maming convention which breaks modern editors for instance.
Make the code leaner to reduce the number of bugs we have to deal. But also because it will make it more simple to follow the code. In that respect, the Bottle framework is a good example.
CherryPy 4 was meant to already break the monolith into specialized packages. It's a good idea that should be pursued, however I don't know where it stands right now.
Finally, we probably want to decide if we shouldn't start relying on third-parties for certain tasks. It would make CherryPy not a self-contained framework any longer but would reduce the source code size drastically.
Community
========
CherryPy has always been a quiet bunch, people use it, are happy about it and don't waste their time. I think it's a compliment to what the project always strove for.
The downside is that the number of people actively working on CherryPy is very low. It is demotivating to them I think.
If we agree on a leaner CherryPy roadmap and we tackle its challenges in a loving, yet harsh, manner. We can probably return to a better situation.
In that regards, I have a feeling we ought to move to github really. BitBucket is good and all but most people are over at github. It would make CherryPy more visible and, hopefully, more lively.
I'd be happy voting to give permissions over the project to people who would get seriously involved.
Delivery
======
Our current delivery workflow is not transparent and quite unclear. I honestly wouldn't know how to properly release CherryPy today. We need to fix this ASAP in my opinion.
I also believe we ought to give a clear delivery schedule (say one every six month as it is quite usual these days).
We should really start a changelog as well. A diff is not a proper log I'm afraid and it's almost impossible to understand what a new release provides or removes these days. It's lucky we are quite conservative.
We also need to clarify which platforms/VM we officially support: CPython 2/3, jython ?, pypy?, ironpython? etc. We also need to define a policy when a bug occurs on one of them only.
Bugs bugs bugs
============
CherryPy has bugs. Many bugs. But, more importantly, complex bugs. This explains why we fail to find the motivation to tackle them. Moreover fixing a bug is a tricky thing since it can break something on a different target (the ssl issue between pypy and cpython for instance).
We need to sort these issues and prioritize them. Some, if not many, will simply be closed for now I'm afraid. Others will have to be dealt promptly if we can.
Considering the size of CherryPy and the fact it's actually a fairly common dependency these days, we ought to ensure we come down to 50 open issues. Above that clearly means something is going wrong.
Documentation
===========
Aside from a few hiccups, I think the new documentation has been a success. There is room for improvment but hopefully it's easier to help in that regards than it used to be.
So there it is, it's not a plan. Just a last call for beloved project. If you've long fancied working on a OSS project with a strong user base, it's your chance to speak up!
Joel Rivera
Dec 30, 2014, 7:42:53 PM12/30/14
to cherryp...@googlegroups.com
Hi!
This is going to be a long email so, take a sit please. ⑁
First of all, as I mentioned on IRC, I think that this changes *need*
to be supported/discussed by Robert and Jason (maybe also Tavo and
Joseph) whose work, support and commitment trough the last years have
given the shape on CherryPy and therefore a place as an authority on
the high level goals on the project (also Remy but I think that the
baton was clearly passed to Robert years ago). At the very least have
an idea of his positions on the project and the realistically available
time and goals that they see on the near future.
I also think that we most see the "big picture". Understand the reasons
on why CherryPy is where it stands (the history) and see the pattern on
the recent years of YouGov implicitly supporting CherryPy with their
employees (current or previous).
A more or less monolithic group with the right incentives to
keep working on cherrypy for a particular use case, with little or none
incentives to move all the things or cover use cases that they are not
using on YouGov. Heck! I think New Relic support CherryPy just to be
able to do business with YouGov.
(Those two paragraph are highly speculative, it's just an observation.)
Having said those political/historical comments I'm going to address
the proposal in-line:
On Tue, 30 Dec 2014 15:44:31 +0100
Sylvain Hellegouarch <s...@defuze.org> wrote:
> Hi folks,
>
> I hope everyone has a good holiday season. Anyway, I was going through
> CherryPy's issue tracker and gosh... we still have plenty. Honestly,
> I'm not sure what to do at this stage.
>
> It seems there are way too many reported issues and too few of us to
> actually do anything concrete to reduce the workload. So what now?
Start screaming and run in circles! :O
> I'm confident CherryPy has its place in web development ecosystem.
> Sure it's not the fastest, nor it is the most trendy web app
> framework these days. But it is simple, flexible and reliable. Many
> people favour those over raw speed or bare capacity. What this means
> is that CherryPy shouldn't die. We're not a Apache project yet ;-)
>
> With that being said, there are various tracks we should pursue to
> really improve the situation. Offge the top of my head:
>
> * Define a sensible and achievable roadmap for the project
> * Identify people willing to actively work on it (and provide them
> with permissions over the project)
> * Clean up our delivery workflow and schedule. Fix our delivered
> packages to avoid the issues we had with platform-dependant
> distributions
> * Go through our bug database, sort them into categories and
> prioritize them
> * Continue on working on the documentation
>
> Overall, nothing new here. Inject some life into the project!
I can certainly help on one or two of those things.
> Roadmap
> =======
>
> As it stands, CherryPy works great and has had a stable API for many
> years. I'm not sure people would appreciate if we started breaking
> that API altogether. Or they'd probably move to greener pastures like
> Flask or Tornado (which would make sense considering how ubiquitous
> these frameworks have become).
>
> So, the point is to be realist about where CherryPy stands and
> continue into that direction. As always, do one thing well rather
> than many poorly. For this reason, I think our best approach is to
> actually make CherryPy more and more lean and clean.
>
> Clean the code first because, honestly it's a bit of a mess (blame
> HTTP, WSGI and Python 2vs3 corner cases) as is our package layout.
> Indeed, let's give up the whole _cp* maming convention which breaks
> modern editors for instance.
How does the _cp* breaks the modern editors? Are you saying that my
editor of the 70's (emacs) is not modern enough? :)
> Make the code leaner to reduce the number of bugs we have to deal.
> But also because it will make it more simple to follow the code. In
> that respect, the Bottle framework is a good example.
I think that the code cleaning part *most* be on a mayor release, I
foresee a lot new bread of bugs coming with the new code base.
> CherryPy 4 was meant to already break the monolith into specialized
> packages. It's a good idea that should be pursued, however I don't
> know where it stands right now.
Maybe Tavo have more info about CP4.
> Finally, we probably want to decide if we shouldn't start relying on
> third-parties for certain tasks. It would make CherryPy not a
> self-contained framework any longer but would reduce the source code
> size drastically.
This is controversial, given that currently nobody is playing the role
of benevolent dictator, and both position are valid in some way.
One could imagine the rationale on the good old times of cherrypy
there was no virtualenv/pip and it was harder to get your setup
right, on 2014/5 this is no longer the case.
But it is still a feature, that is paying the price on the _cp/compat
stuff. Most of the CP code reflect the trade-off on having a clean
*public* API and just make the more straight forward of the ways the
internal library stuff.
OTOH given the monolithic approach, CP was one of the first web
frameworks to support Python3. As a side effect it isolates itself from
the incentives of the version pushing on the dependencies. (to include
the subprocess module from the stdlib might give you an idea on how
much the backward compatibility and monolithic approach gets pushed)
> Community
> ========
>
> CherryPy has always been a quiet bunch, people use it, are happy
> about it and don't waste their time. I think it's a compliment to
> what the project always strove for.
>
> The downside is that the number of people actively working on
> CherryPy is very low. It is demotivating to them I think.
I agree, there is no fancy stuff going on. In particular people are
less verbal when the stuff that they are working on is not hot on the
startup market. We tend to showoff to see how cool we are, either to
be popular or to be hired. *fast* *efficient* *novelty* *web scale*
*how many millions of req/seq does framework X can do?*
If you're not one of those then you just quietly use it on the
internal applications, median to low traffic websites or quick hacks and
that's it.
For what I have seen, the most public use case in this days is on
using CherryPy as HTTP server along with Django, Flask or Bottle.
> If we agree on a leaner CherryPy roadmap and we tackle its challenges
> in a loving, yet harsh, manner. We can probably return to a better
> situation.
>
> In that regards, I have a feeling we ought to move to github really.
> BitBucket is good and all but most people are over at github. It
> would make CherryPy more visible and, hopefully, more lively.
>
> I'd be happy voting to give permissions over the project to people who
> would get seriously involved.
I kinda remember that bitbucket was originally chosen because of
mercurial and as a way to support the python community. I personally
suspect that mercurial is more popular with the maintainers of CP,
hence the reluctance to migrate to git. github -> rails/git
But given the current state of the world, it has become
rather irrelevant.
This is an outreach effort and we must accept the rationale that the
change is just to be more "cool" and therefore deny the original
idealist position. Also we must migrate the issues, I think we should
do it in a more manual way, otherwise some old-bugs are going to be
traveling around since the Trac era.
(Disclaimer: I do prefer mercurial :( but I agree from the outreach
point of view)
> Delivery
> ======
>
> Our current delivery workflow is not transparent and quite unclear. I
> honestly wouldn't know how to properly release CherryPy today. We
> need to fix this ASAP in my opinion.
>
> I also believe we ought to give a clear delivery schedule (say one
> every six month as it is quite usual these days).
>
> We should really start a changelog as well. A diff is not a proper
> log I'm afraid and it's almost impossible to understand what a new
> release provides or removes these days. It's lucky we are quite
> conservative.
We need a release manager that:
1. Have time
2. Can follow the clue on where the project is moving
3. Know-how on the code base
4. Communicative dude that can coordinate with other individuals.
5. Be responsible on setting the limits on how much features can be on
each release to have manageable change logs with reasonable gradual
changes.
I must say that I have personally talked this issue with Jason on
the previous PyCon, he and Robert are the only ones who can
deploy CP to pypi. Jason it is looking to have a backup (official?)
release manager. (maybe more than one person is needed to cover this
role, or have a better segmentation)
> We also need to clarify which platforms/VM we officially support:
> CPython 2/3, jython ?, pypy?, ironpython? etc. We also need to define
> a policy when a bug occurs on one of them only.
I think that this was aggravated for the old promise of extreme
backwards compatibility and not having the human time to actually test
the new versions and all the three mayor OSs and on each implementation.
Tavo had some CI machines, I'm not sure where or how that stuff gets
deployed.
> Bugs bugs bugs
> ============
>
> CherryPy has bugs. Many bugs. But, more importantly, complex bugs.
> This explains why we fail to find the motivation to tackle them.
> Moreover fixing a bug is a tricky thing since it can break something
> on a different target (the ssl issue between pypy and cpython for
> instance).
We do have a lot of issues, and from time to time a few courageous
individuals dare to take the issue (of having a lot of bugs) on his own
hands, as an individual trying to help on a monolithic code base with a
promise of clean public API with a little regard on the internals, it's
pretty hard. Also some of the bugs are for old versions of python,
that probably the volunteer/contributor does not have properly setup on
his machine.
The situation is:
1. It's going to take time on the mere setup.
2. Take more time on understand the conventions on the code base.
3. And then actually make something about the reported bug.
4. If he can found something, then it will make a comment on the issue
and probably someone is going to reply on a couple of months.
I think that the problem is that we are asking a lot to the newbie and
giving to little.
Of course we need contributors, but it is easier to attract people with
well classified issues and with some rules on expected response times to
review the issue and provide feedback.
Also it could help some documentation on how to get started and
point the internal architecture and the idiosyncrasies on the code base.
> We need to sort these issues and prioritize them. Some, if not many,
> will simply be closed for now I'm afraid. Others will have to be
> dealt promptly if we can.
>
> Considering the size of CherryPy and the fact it's actually a fairly
> common dependency these days, we ought to ensure we come down to 50
> open issues. Above that clearly means something is going wrong.
>
> Documentation
> ===========
>
> Aside from a few hiccups, I think the new documentation has been a
> success. There is room for improvment but hopefully it's easier to
> help in that regards than it used to be.
The rewrite of the documentation was a great effort. In particular very
few people can produce documentation, given that is required to know
enough cherrypy, have a good technical english (I kinda sucks in this),
have empathy to see the docs as a new user (or the target audience) and
have the incentives to do so (the cool technology stuff).
> So there it is, it's not a plan. Just a last call for beloved
> project. If you've long fancied working on a OSS project with a
> strong user base, it's your chance to speak up!
>
> Early happy new year folks!
In general I get the impression that most of the comments are regarding
on having an up to date and enforced development guidelines. The fact
that we are discussing this on the cherrypy-*users* is a reflection on
the issues that we are discussing.
Maybe we could start a wiki and contribute to a more formal guidance
on how to contribute and what are the commitments that we can make.
This are the relevant wiki pages of the old dev team (most of them are
formated for the Trac wiki):
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyInvolved
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPySpec
https://bitbucket.org/cherrypy/cherrypy/wiki/CodeConventions
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyTeam
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyInstall
Have a great day and happy new year!
--
Rivera²
This is going to be a long email so, take a sit please. ⑁
First of all, as I mentioned on IRC, I think that this changes *need*
to be supported/discussed by Robert and Jason (maybe also Tavo and
Joseph) whose work, support and commitment trough the last years have
given the shape on CherryPy and therefore a place as an authority on
the high level goals on the project (also Remy but I think that the
baton was clearly passed to Robert years ago). At the very least have
an idea of his positions on the project and the realistically available
time and goals that they see on the near future.
I also think that we most see the "big picture". Understand the reasons
on why CherryPy is where it stands (the history) and see the pattern on
the recent years of YouGov implicitly supporting CherryPy with their
employees (current or previous).
A more or less monolithic group with the right incentives to
keep working on cherrypy for a particular use case, with little or none
incentives to move all the things or cover use cases that they are not
using on YouGov. Heck! I think New Relic support CherryPy just to be
able to do business with YouGov.
(Those two paragraph are highly speculative, it's just an observation.)
Having said those political/historical comments I'm going to address
the proposal in-line:
On Tue, 30 Dec 2014 15:44:31 +0100
Sylvain Hellegouarch <s...@defuze.org> wrote:
> Hi folks,
>
> I hope everyone has a good holiday season. Anyway, I was going through
> CherryPy's issue tracker and gosh... we still have plenty. Honestly,
> I'm not sure what to do at this stage.
>
> It seems there are way too many reported issues and too few of us to
> actually do anything concrete to reduce the workload. So what now?
> I'm confident CherryPy has its place in web development ecosystem.
> Sure it's not the fastest, nor it is the most trendy web app
> framework these days. But it is simple, flexible and reliable. Many
> people favour those over raw speed or bare capacity. What this means
> is that CherryPy shouldn't die. We're not a Apache project yet ;-)
>
> With that being said, there are various tracks we should pursue to
> really improve the situation. Offge the top of my head:
>
> * Define a sensible and achievable roadmap for the project
> * Identify people willing to actively work on it (and provide them
> with permissions over the project)
> * Clean up our delivery workflow and schedule. Fix our delivered
> packages to avoid the issues we had with platform-dependant
> distributions
> * Go through our bug database, sort them into categories and
> prioritize them
> * Continue on working on the documentation
>
> Overall, nothing new here. Inject some life into the project!
> Roadmap
> =======
>
> As it stands, CherryPy works great and has had a stable API for many
> years. I'm not sure people would appreciate if we started breaking
> that API altogether. Or they'd probably move to greener pastures like
> Flask or Tornado (which would make sense considering how ubiquitous
> these frameworks have become).
>
> So, the point is to be realist about where CherryPy stands and
> continue into that direction. As always, do one thing well rather
> than many poorly. For this reason, I think our best approach is to
> actually make CherryPy more and more lean and clean.
>
> Clean the code first because, honestly it's a bit of a mess (blame
> HTTP, WSGI and Python 2vs3 corner cases) as is our package layout.
> Indeed, let's give up the whole _cp* maming convention which breaks
> modern editors for instance.
editor of the 70's (emacs) is not modern enough? :)
> Make the code leaner to reduce the number of bugs we have to deal.
> But also because it will make it more simple to follow the code. In
> that respect, the Bottle framework is a good example.
foresee a lot new bread of bugs coming with the new code base.
> CherryPy 4 was meant to already break the monolith into specialized
> packages. It's a good idea that should be pursued, however I don't
> know where it stands right now.
> Finally, we probably want to decide if we shouldn't start relying on
> third-parties for certain tasks. It would make CherryPy not a
> self-contained framework any longer but would reduce the source code
> size drastically.
of benevolent dictator, and both position are valid in some way.
One could imagine the rationale on the good old times of cherrypy
there was no virtualenv/pip and it was harder to get your setup
right, on 2014/5 this is no longer the case.
But it is still a feature, that is paying the price on the _cp/compat
stuff. Most of the CP code reflect the trade-off on having a clean
*public* API and just make the more straight forward of the ways the
internal library stuff.
OTOH given the monolithic approach, CP was one of the first web
frameworks to support Python3. As a side effect it isolates itself from
the incentives of the version pushing on the dependencies. (to include
the subprocess module from the stdlib might give you an idea on how
much the backward compatibility and monolithic approach gets pushed)
> Community
> ========
>
> CherryPy has always been a quiet bunch, people use it, are happy
> about it and don't waste their time. I think it's a compliment to
> what the project always strove for.
>
> The downside is that the number of people actively working on
> CherryPy is very low. It is demotivating to them I think.
less verbal when the stuff that they are working on is not hot on the
startup market. We tend to showoff to see how cool we are, either to
be popular or to be hired. *fast* *efficient* *novelty* *web scale*
*how many millions of req/seq does framework X can do?*
If you're not one of those then you just quietly use it on the
internal applications, median to low traffic websites or quick hacks and
that's it.
For what I have seen, the most public use case in this days is on
using CherryPy as HTTP server along with Django, Flask or Bottle.
> If we agree on a leaner CherryPy roadmap and we tackle its challenges
> in a loving, yet harsh, manner. We can probably return to a better
> situation.
>
> In that regards, I have a feeling we ought to move to github really.
> BitBucket is good and all but most people are over at github. It
> would make CherryPy more visible and, hopefully, more lively.
>
> I'd be happy voting to give permissions over the project to people who
> would get seriously involved.
mercurial and as a way to support the python community. I personally
suspect that mercurial is more popular with the maintainers of CP,
hence the reluctance to migrate to git. github -> rails/git
But given the current state of the world, it has become
rather irrelevant.
This is an outreach effort and we must accept the rationale that the
change is just to be more "cool" and therefore deny the original
idealist position. Also we must migrate the issues, I think we should
do it in a more manual way, otherwise some old-bugs are going to be
traveling around since the Trac era.
(Disclaimer: I do prefer mercurial :( but I agree from the outreach
point of view)
> Delivery
> ======
>
> Our current delivery workflow is not transparent and quite unclear. I
> honestly wouldn't know how to properly release CherryPy today. We
> need to fix this ASAP in my opinion.
>
> I also believe we ought to give a clear delivery schedule (say one
> every six month as it is quite usual these days).
>
> We should really start a changelog as well. A diff is not a proper
> log I'm afraid and it's almost impossible to understand what a new
> release provides or removes these days. It's lucky we are quite
> conservative.
1. Have time
2. Can follow the clue on where the project is moving
3. Know-how on the code base
4. Communicative dude that can coordinate with other individuals.
5. Be responsible on setting the limits on how much features can be on
each release to have manageable change logs with reasonable gradual
changes.
I must say that I have personally talked this issue with Jason on
the previous PyCon, he and Robert are the only ones who can
deploy CP to pypi. Jason it is looking to have a backup (official?)
release manager. (maybe more than one person is needed to cover this
role, or have a better segmentation)
> We also need to clarify which platforms/VM we officially support:
> CPython 2/3, jython ?, pypy?, ironpython? etc. We also need to define
> a policy when a bug occurs on one of them only.
backwards compatibility and not having the human time to actually test
the new versions and all the three mayor OSs and on each implementation.
Tavo had some CI machines, I'm not sure where or how that stuff gets
deployed.
> Bugs bugs bugs
> ============
>
> CherryPy has bugs. Many bugs. But, more importantly, complex bugs.
> This explains why we fail to find the motivation to tackle them.
> Moreover fixing a bug is a tricky thing since it can break something
> on a different target (the ssl issue between pypy and cpython for
> instance).
individuals dare to take the issue (of having a lot of bugs) on his own
hands, as an individual trying to help on a monolithic code base with a
promise of clean public API with a little regard on the internals, it's
pretty hard. Also some of the bugs are for old versions of python,
that probably the volunteer/contributor does not have properly setup on
his machine.
The situation is:
1. It's going to take time on the mere setup.
2. Take more time on understand the conventions on the code base.
3. And then actually make something about the reported bug.
4. If he can found something, then it will make a comment on the issue
and probably someone is going to reply on a couple of months.
I think that the problem is that we are asking a lot to the newbie and
giving to little.
Of course we need contributors, but it is easier to attract people with
well classified issues and with some rules on expected response times to
review the issue and provide feedback.
Also it could help some documentation on how to get started and
point the internal architecture and the idiosyncrasies on the code base.
> We need to sort these issues and prioritize them. Some, if not many,
> will simply be closed for now I'm afraid. Others will have to be
> dealt promptly if we can.
>
> Considering the size of CherryPy and the fact it's actually a fairly
> common dependency these days, we ought to ensure we come down to 50
> open issues. Above that clearly means something is going wrong.
>
> Documentation
> ===========
>
> Aside from a few hiccups, I think the new documentation has been a
> success. There is room for improvment but hopefully it's easier to
> help in that regards than it used to be.
few people can produce documentation, given that is required to know
enough cherrypy, have a good technical english (I kinda sucks in this),
have empathy to see the docs as a new user (or the target audience) and
have the incentives to do so (the cool technology stuff).
> So there it is, it's not a plan. Just a last call for beloved
> project. If you've long fancied working on a OSS project with a
> strong user base, it's your chance to speak up!
>
> Early happy new year folks!
on having an up to date and enforced development guidelines. The fact
that we are discussing this on the cherrypy-*users* is a reflection on
the issues that we are discussing.
Maybe we could start a wiki and contribute to a more formal guidance
on how to contribute and what are the commitments that we can make.
This are the relevant wiki pages of the old dev team (most of them are
formated for the Trac wiki):
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyInvolved
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPySpec
https://bitbucket.org/cherrypy/cherrypy/wiki/CodeConventions
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyTeam
https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyInstall
Have a great day and happy new year!
--
Rivera²
Nic Young
Dec 31, 2014, 2:02:46 AM12/31/14
to cherryp...@googlegroups.com
Hi,
I just wanted to give a little background on myself since I have not posted to this list in quite some time.On Tue, Dec 30, 2014 at 5:45 PM, Joel Rivera <riv...@joel.mx> wrote:
On Tue, 30 Dec 2014 15:44:31 +0100
Sylvain Hellegouarch <s...@defuze.org> wrote:
> Clean the code first because, honestly it's a bit of a mess (blame
> HTTP, WSGI and Python 2vs3 corner cases) as is our package layout.
> Indeed, let's give up the whole _cp* maming convention which breaks
> modern editors for instance.
How does the _cp* breaks the modern editors? Are you saying that my
editor of the 70's (emacs) is not modern enough? :)
Perhaps he is saying that this is not the convention used by the majority of Python projects out there? I do not have enough experience with the CherryPy code itself to understand the historical reasons of why this was done. But, if we are trying to lower the bar of entry for new developers we definitely want to follow standard Python idioms where it makes sense.
> In that regards, I have a feeling we ought to move to github really.
> BitBucket is good and all but most people are over at github. It
> would make CherryPy more visible and, hopefully, more lively.
>
> I'd be happy voting to give permissions over the project to people who
> would get seriously involved.
I kinda remember that bitbucket was originally chosen because of
mercurial and as a way to support the python community. I personally
suspect that mercurial is more popular with the maintainers of CP,
hence the reluctance to migrate to git. github -> rails/git
But given the current state of the world, it has become
rather irrelevant.
This is an outreach effort and we must accept the rationale that the
change is just to be more "cool" and therefore deny the original
idealist position. Also we must migrate the issues, I think we should
do it in a more manual way, otherwise some old-bugs are going to be
traveling around since the Trac era.
(Disclaimer: I do prefer mercurial :( but I agree from the outreach
point of view)
I think switching to Github is a good idea. The momentum on where to
host open source projects has swung in Github's favor over the years. If
we are looking to bring in new developers and if the project being on
Github is perceived as *cool*, so be it, as long as it raises the visibility of the project.
Tavo had some CI machines, I'm not sure where or how that stuff gets
deployed.
Another advantage to moving to Github is a lot of CI tools integrate with Github and a lot of them are free for Open Source projects, like Travis CI: https://travis-ci.org/
> Documentation
> ===========
>
> Aside from a few hiccups, I think the new documentation has been a
> success. There is room for improvment but hopefully it's easier to
> help in that regards than it used to be.
The rewrite of the documentation was a great effort. In particular very
few people can produce documentation, given that is required to know
enough cherrypy, have a good technical english (I kinda sucks in this),
have empathy to see the docs as a new user (or the target audience) and
have the incentives to do so (the cool technology stuff).
The new documentation is great! It is way better than what was previously there. The documentation is one of the aspects I would definitely love to contribute my time. I believe that well written docs will also be another way to get more developers to contribute.
In general I get the impression that most of the comments are regarding
on having an up to date and enforced development guidelines. The fact
that we are discussing this on the cherrypy-*users* is a reflection on
the issues that we are discussing.
Was there not a cherrypy-devs mailing list at one time? If not perhaps we should start it up again?
Well there is my humble opinion.
Hopefully everybody has a great and safe New Years!
Hopefully everybody has a great and safe New Years!
--
Cheers,
Nic Young
Nic Young
Sylvain Hellegouarch
Dec 31, 2014, 4:12:38 AM12/31/14
to cherryp...@googlegroups.com
Hi Joel,
Thanks for the reply.
How does the _cp* breaks the modern editors? Are you saying that my
editor of the 70's (emacs) is not modern enough? :)
I don't really mind either to be fair because I'm also using a bare emacs. However, as Nic suggests, it's also a style issue. I assume the fact some modules start with a _ indicates they are internals. But I'm not sure it's as clear as one would actually hope.
I wouldn't mind inputs from people using pycharm or pydev in regards to refactoring CherryPy code.
> Finally, we probably want to decide if we shouldn't start relying on
> third-parties for certain tasks. It would make CherryPy not a
> self-contained framework any longer but would reduce the source code
> size drastically.
This is controversial, given that currently nobody is playing the role
of benevolent dictator, and both position are valid in some way.
One could imagine the rationale on the good old times of cherrypy
there was no virtualenv/pip and it was harder to get your setup
right, on 2014/5 this is no longer the case.
But it is still a feature, that is paying the price on the _cp/compat
stuff. Most of the CP code reflect the trade-off on having a clean
*public* API and just make the more straight forward of the ways the
internal library stuff.
OTOH given the monolithic approach, CP was one of the first web
frameworks to support Python3. As a side effect it isolates itself from
the incentives of the version pushing on the dependencies. (to include
the subprocess module from the stdlib might give you an idea on how
much the backward compatibility and monolithic approach gets pushed)
I agree with you. I'm not entirely convinced using dependencies is the right approach overall. It has drawbacks that you mention.
Plus it would probably require a lot of work to migrate to a dependency.
> Community
> ========
>
> CherryPy has always been a quiet bunch, people use it, are happy
> about it and don't waste their time. I think it's a compliment to
> what the project always strove for.
>
> The downside is that the number of people actively working on
> CherryPy is very low. It is demotivating to them I think.
I agree, there is no fancy stuff going on. In particular people are
less verbal when the stuff that they are working on is not hot on the
startup market. We tend to showoff to see how cool we are, either to
be popular or to be hired. *fast* *efficient* *novelty* *web scale*
*how many millions of req/seq does framework X can do?*
If you're not one of those then you just quietly use it on the
internal applications, median to low traffic websites or quick hacks and
that's it.
For what I have seen, the most public use case in this days is on
using CherryPy as HTTP server along with Django, Flask or Bottle.
So have I. This comes back to my first point, what do we want to do with CherryPy.
We have competition (using it in a noble sense here) on the HTTP serving side with Tornado as well as on the application side with Bottle or Flask.
Where do we want to stand? Where to put our effort if people don't actually use the application framework much? Maybe cheroot is the way to go (by the way, that name isn't doing the project any favour I think).
> If we agree on a leaner CherryPy roadmap and we tackle its challenges
> in a loving, yet harsh, manner. We can probably return to a better
> situation.
>
> In that regards, I have a feeling we ought to move to github really.
> BitBucket is good and all but most people are over at github. It
> would make CherryPy more visible and, hopefully, more lively.
>
> I'd be happy voting to give permissions over the project to people who
> would get seriously involved.
I kinda remember that bitbucket was originally chosen because of
mercurial and as a way to support the python community. I personally
suspect that mercurial is more popular with the maintainers of CP,
hence the reluctance to migrate to git. github -> rails/git
But given the current state of the world, it has become
rather irrelevant.
This is an outreach effort and we must accept the rationale that the
change is just to be more "cool" and therefore deny the original
idealist position. Also we must migrate the issues, I think we should
do it in a more manual way, otherwise some old-bugs are going to be
traveling around since the Trac era.
(Disclaimer: I do prefer mercurial :( but I agree from the outreach
point of view)
I couldn't care less between mercurial and github for this project. Moving to github would be about the community size and our reach to a greater audience.
> We also need to clarify which platforms/VM we officially support:
> CPython 2/3, jython ?, pypy?, ironpython? etc. We also need to define
> a policy when a bug occurs on one of them only.
I think that this was aggravated for the old promise of extreme
backwards compatibility and not having the human time to actually test
the new versions and all the three mayor OSs and on each implementation.
Tavo had some CI machines, I'm not sure where or how that stuff gets
deployed.
Still, we need human beings to actually read and act upon the results from those builds. Otherwise, it's moot :)
Such a documentation was planned but I didn't write it in the end because I have no ideas where to begin about it :(
I still consider that if cleaned up a bit our code/design, it would make more sense natively. Right now, going through the code can be painful.
In general I get the impression that most of the comments are regarding
on having an up to date and enforced development guidelines. The fact
that we are discussing this on the cherrypy-*users* is a reflection on
the issues that we are discussing.
Much agreed. Maybe I was being disruptive when we only need a more visible governance.
Sylvain Hellegouarch
Dec 31, 2014, 4:39:32 AM12/31/14
to cherryp...@googlegroups.com
Hi Nic,
2014-12-31 6:45 GMT+01:00 Nic Young <nry...@gmail.com>:
I have been using CherryPy professionally for approximately 2 years and we just recently started upgrading from CherryPy 3.1.x to 3.2.6 and it is great! I also just recently opened my first pull request to help clean up some grammar mistakes in the docs (wohoo!). Since I do not have much technical experience dealing with the inner workings of CherryPy I will just be commenting on the community aspects below.Hi,I just wanted to give a little background on myself since I have not posted to this list in quite some time.
You're more than welcome to do so!
On Tue, Dec 30, 2014 at 5:45 PM, Joel Rivera <riv...@joel.mx> wrote:On Tue, 30 Dec 2014 15:44:31 +0100
Sylvain Hellegouarch <s...@defuze.org> wrote:> Clean the code first because, honestly it's a bit of a mess (blame
> HTTP, WSGI and Python 2vs3 corner cases) as is our package layout.
> Indeed, let's give up the whole _cp* maming convention which breaks
> modern editors for instance.
How does the _cp* breaks the modern editors? Are you saying that my
editor of the 70's (emacs) is not modern enough? :)Perhaps he is saying that this is not the convention used by the majority of Python projects out there? I do not have enough experience with the CherryPy code itself to understand the historical reasons of why this was done. But, if we are trying to lower the bar of entry for new developers we definitely want to follow standard Python idioms where it makes sense.
In a way it is a standard idiom to notify a symbol is internal only when you start its name with a _. This is just not that common for modules and it can be confusing.
I think switching to Github is a good idea. The momentum on where to host open source projects has swung in Github's favor over the years. If we are looking to bring in new developers and if the project being on Github is perceived as *cool*, so be it, as long as it raises the visibility of the project.
Tavo had some CI machines, I'm not sure where or how that stuff gets
deployed.Another advantage to moving to Github is a lot of CI tools integrate with Github and a lot of them are free for Open Source projects, like Travis CI: https://travis-ci.org/
Wouldn't travis be able to use a mercurial repository?
In general I get the impression that most of the comments are regarding
on having an up to date and enforced development guidelines. The fact
that we are discussing this on the cherrypy-*users* is a reflection on
the issues that we are discussing.Was there not a cherrypy-devs mailing list at one time? If not perhaps we should start it up again?
That list still exists but it's not been used for years I'm afraid. Until we grow a little, I'm not certain this would help :)
Cheers,
Konstantin Molchanov
Jan 6, 2015, 2:51:52 AM1/6/15
to cherryp...@googlegroups.com
Hi,
I've been using CherryPy in my personal projects for several years now. I would like to address some of your points.
we probably want to decide if we shouldn't start relying on third-parties for certain tasks
Depends on a particular "certain task." For example, Bottle-like and Django-like routing could, and I think should, be a part of the core.
For example, currently, to map routes with regexes, the RoutesDispatcher with the Routes package must be used. This turns a simple task of routing into a complicated one (and "common tasks should be fast and easy," right?). So, answering your question, we already rely on third-parties for certain tasks, and such tasks are not necessarily uncommon.
For other tasks—templating comes to mind—third-parties are better. So CherryPy probably shouldn't invent its own templating engine like Bottle.
In that regards, I have a feeling we ought to move to github really.
I think, it doesn't really matter. We should focus on measurable things and put effort where it pays off. Like, improving the docs and simplifying the configuration routine to make life easier for beginners. Or post on /r/python more often to let the Python community know CherryPy exists.
If we make the Bitbucket → GitHub and hg → git move, what would we achieve? Being with the cool guys doesn't mean being one, so per se such a move doesn't mean anything but trading a lot of effort for an uncertain possibility of someone considering CherryPy cooler based on its code hosting choice. I think we should not rely on that.
I think we have much bigger problems than that.
---
A few concrete points.
We should look at CherryPy as a product. Our customers are Python programmers. What would attract them?
A new cool site would. Like all humans, programmers love fancy stuff even if they pretend not to care.
Reddit posts would. Lots of Python programmers learn about new stuff on r/python. Also, r/learnpython is where all the younglings live, we should post tutorials there.
Moving from IRC to a communication channel that is easier to enter for newbies. Maybe an open Skype chat would be a good option (at least, I'd love it).
Sylvain Hellegouarch
Jan 6, 2015, 8:06:09 AM1/6/15
to cherryp...@googlegroups.com
Hello,
Thanks for your feedback :)
2015-01-06 8:51 GMT+01:00 Konstantin Molchanov <moig...@gmail.com>:
Hi,I've been using CherryPy in my personal projects for several years now. I would like to address some of your points.we probably want to decide if we shouldn't start relying on third-parties for certain tasksDepends on a particular "certain task." For example, Bottle-like and Django-like routing could, and I think should, be a part of the core.
Should they? This could also be handled by external packages that provide such features.
For example, currently, to map routes with regexes, the RoutesDispatcher with the Routes package must be used. This turns a simple task of routing into a complicated one (and "common tasks should be fast and easy," right?). So, answering your question, we already rely on third-parties for certain tasks, and such tasks are not necessarily uncommon.
We rely on 3rd parties only for non-core features which is fine indeed. For core aspects of CherryPy, it's a different question.
For other tasks—templating comes to mind—third-parties are better. So CherryPy probably shouldn't invent its own templating engine like Bottle.
Unlikely to happened so we're fine on this one.
In that regards, I have a feeling we ought to move to github really.I think, it doesn't really matter. We should focus on measurable things and put effort where it pays off. Like, improving the docs and simplifying the configuration routine to make life easier for beginners. Or post on /r/python more often to let the Python community know CherryPy exists.
Which is basically the point to move to github. It's not about git vs mercurial. It's about the community size and the fact github is the defacto OSS hub these days. More visivility...
---A few concrete points.We should look at CherryPy as a product. Our customers are Python programmers. What would attract them?
That is indeed the question I initially asked ;)
A new cool site would. Like all humans, programmers love fancy stuff even if they pretend not to care.
I don't quite understand, you are against acting like the cool guy by moving to github but you want to look fancy enough? I'm not following.
Thanks,
Konstantin Molchanov
Jan 6, 2015, 8:25:55 AM1/6/15
to cherryp...@googlegroups.com
Sorry if I couldn't present my points well. I'll try to explain some of them better.
Should they? This could also be handled by external packages that provide such features.
Well, that's just my opinion. I think, this kind of routing is much more common than CherryPy's approach, so CherryPy should conform and offer it out of the box.
Which is basically the point to move to github. It's not about git vs mercurial. It's about the community size and the fact github is the defacto OSS hub these days. More visivility...
My point is that moving to GitHub doesn't give you more visibility. The fact that GitHub is more popular doesn't mean that CherryPy will get more attention by simply moving to it.
I don't quite understand, you are against acting like the cool guy by moving to github but you want to look fancy enough? I'm not following.
I don't think moving to GitHub is acting like the cool guy. I am against it because I can't see enough value in this effort.
A new site, on the other hand, will create a positive image more efficiently than a source hosting choice.
I mean, when you go to django-project.org, do you first check out the docs, the design, the tutorials, or do you go see where the Django guys keep their code?
Of course, I can be totally wrong, but I care about CherryPy and wanted to share my point of view as a user.
Robert
Jan 6, 2015, 9:05:43 AM1/6/15
to cherryp...@googlegroups.com
It would probably benefit CherryPy to do both. A new site and moving the source to github. Resources to do both is probably scarce though.
Bob
Bob
Sylvain Hellegouarch
Jan 6, 2015, 10:17:45 AM1/6/15
to cherryp...@googlegroups.com
2015-01-06 14:25 GMT+01:00 Konstantin Molchanov <moig...@gmail.com>:
Sorry if I couldn't present my points well. I'll try to explain some of them better.
I'm sorry if I sounded a bit short. I appreciate your input.
Should they? This could also be handled by external packages that provide such features.Well, that's just my opinion. I think, this kind of routing is much more common than CherryPy's approach, so CherryPy should conform and offer it out of the box.
Well, I'm all for features that make CherryPy stand. I guess I wasn't seeing how it would make it more appealing but I'm perhaps wrong :)
Which is basically the point to move to github. It's not about git vs mercurial. It's about the community size and the fact github is the defacto OSS hub these days. More visivility...My point is that moving to GitHub doesn't give you more visibility. The fact that GitHub is more popular doesn't mean that CherryPy will get more attention by simply moving to it.
I agree with your earlier statement that we can't measure the impact of this move. This is what annoys me indeed :/
I don't quite understand, you are against acting like the cool guy by moving to github but you want to look fancy enough? I'm not following.I don't think moving to GitHub is acting like the cool guy. I am against it because I can't see enough value in this effort.A new site, on the other hand, will create a positive image more efficiently than a source hosting choice.I mean, when you go to django-project.org, do you first check out the docs, the design, the tutorials, or do you go see where the Django guys keep their code?Of course, I can be totally wrong, but I care about CherryPy and wanted to share my point of view as a user.
I'm really happy seeing people caring for it so thanks a lot for your time!
Sylvain Hellegouarch
Jan 6, 2015, 10:20:22 AM1/6/15
to cherryp...@googlegroups.com
Hi Robert,
2015-01-06 15:05 GMT+01:00 Robert <sig...@gmail.com>:
It would probably benefit CherryPy to do both. A new site and moving the source to github. Resources to do both is probably scarce though.
Bob
I hadn't realised our website was lacking actually. I thought it was, simple yet good enough. It's interesting folks think we need a newer one. But I agree with you, for this we lack resources :(
Eric Larson
Jan 6, 2015, 8:29:41 PM1/6/15
to cherryp...@googlegroups.com
FWIW, I'm replying to Joel as I seem have lost Sylvain's original post.
I recently started writing a project in Flask. The experience might be
helpful finding some direction for CherryPy.
First off, the big win using Flask was the wealth of plugins. While
Flask is "micro" framework, you can get a Django-like site up and
running thanks to plugins like Flask-Admin, Flask-SQLAlchemy, etc. This
seemed to work well because there are "blueprints" that allow a plugin
to be "mounted" (to use a cp term) within an application.
CherryPy actually makes using other apps *really* easy. Just import the
module and set it as an attribute on your root object. In terms of
marketing, we could mention this sort of integration more. It also might
be helpful to look through the tools wiki and see if we can refresh some of
them. CherryPy tools are relatively slow to rot, so renaming them to
something structured like "cherrypy-sqlalchemy" or "cherrypy-jinja2"
could help promote more obvious best practices. Sylvain already has
examples for this so packaging them up into "cherrypy-*" packages and
linking to them in the docs seems like a great step forward.
While Flask's plugins were handy, actually programming in Flask is plain
old nasty. CherryPy feels much more pythonic and affords more obivous
connections to HTTP. Flask leaks Werkzeug and doesn't clarify how and if
you should use the underlying framework. Organizing the source code is
tricky as Flask makes it easy to create circular dependencies as it uses
imports to include functionality. This is similar to CherryPy, but
generally, CherryPy does a better job making the framework imports
seamlessly integrate along side the thread locals.
All, this said, Flask has become popular in spite of its warts. One
small theory is that the docs seem to be updated with work arounds and
suggestions that help a new developer get "unstuck" from Flask's design
decisions. Maybe a best practices section would be valuable where
problems found on the mailing list can be codified in the docs along
side recommendations for using the "cherrypy-*" packages I mentioned
above.
To summarize the above suggestions:
1. Take Sylvains examples and package up the database and templating
examples into "cherrypy-*" packages. Put them on Github and release
them to PyPI.
2. Add a best practices section in the docs that point to the
"cherrpy-*" packages and include any other obvious gotchas people
run into. Seeing as this would be an ongoing effort, copying many
of the recommendations in Sylvains example app would be an excellent
place to start iterating.
Hopefully these suggestions don't sound like a massive amount of
work. I'm happy to help setting up the "cherrypy-*" packages and getting
things like docs automatically building on read the docs and travis
working.
In my Flask app, where still ended up using CherryPy was as a standalone
server. Flask (and most wsgi frameworks) don't provide a production
ready server out of the box. Therefore, if you want to provide a single
command to run your app, you have to handle that aspect yourself. In my
use case, my package has two processes, a master and worker. The worker
needed to run a background thread that would ping the master with a
hearbeat when it started and send a "bye" message when it
exited. CherryPy made this extremely easy and convenient. A user of my
package can install it and immediately run either process using a single
command. This is a great feature!
Looking at the future of CherryPy, my suggestions above pertain
primarily to the "framework" portion. The CherryPy server could also use
some new features. It would be fantastic to allow starting more than one
process (a la Gunicorn) as well as allow for an "async" mode. The goal
is simply to reveal CherryPy as a valid option you can include in your
code, no matter the type of application. CherryPy immediately is
disregarded at times because it is a single process or because it can't
handle 10k connections. Implementing this, in addition to being
interesting, could be a great target for CherryPy 4 that would promote
using CherryPy with other micro-frameworks.
Obviously, the improvements to the CherryPy server are very "hand wavy",
so please don't assume these are required. We've used gevent with
CherryPy to improve performance over more connections, so that could be
one tactic on the async front. Allowing multiple processes along with
threadpools is somethng flup has done for a long, so it is definitely
possible. Of course, if no one is interested in implementing it, then it
most definitely won't happen. The point is that there are some concrete
improvements in the server that might not only garner new attention to
CherryPy, but could be fun code to write.
Generally, it feels like CherryPy could find a nice niche bring together
a web interface for a specialized service or daemon. Some services
require different server paradigms, so that is one direction to consider
taking CherryPy in the future.
Obviously, these are just my opinions. Sylvain, feel free to let me know
if it would be helpful to create packages for the example tools /
plugins and I'll dive in.
Obviously, this is all just my humble opinion!
Eric
--
Sent with my mu4e
I recently started writing a project in Flask. The experience might be
helpful finding some direction for CherryPy.
First off, the big win using Flask was the wealth of plugins. While
Flask is "micro" framework, you can get a Django-like site up and
running thanks to plugins like Flask-Admin, Flask-SQLAlchemy, etc. This
seemed to work well because there are "blueprints" that allow a plugin
to be "mounted" (to use a cp term) within an application.
CherryPy actually makes using other apps *really* easy. Just import the
module and set it as an attribute on your root object. In terms of
marketing, we could mention this sort of integration more. It also might
be helpful to look through the tools wiki and see if we can refresh some of
them. CherryPy tools are relatively slow to rot, so renaming them to
something structured like "cherrypy-sqlalchemy" or "cherrypy-jinja2"
could help promote more obvious best practices. Sylvain already has
examples for this so packaging them up into "cherrypy-*" packages and
linking to them in the docs seems like a great step forward.
While Flask's plugins were handy, actually programming in Flask is plain
old nasty. CherryPy feels much more pythonic and affords more obivous
connections to HTTP. Flask leaks Werkzeug and doesn't clarify how and if
you should use the underlying framework. Organizing the source code is
tricky as Flask makes it easy to create circular dependencies as it uses
imports to include functionality. This is similar to CherryPy, but
generally, CherryPy does a better job making the framework imports
seamlessly integrate along side the thread locals.
All, this said, Flask has become popular in spite of its warts. One
small theory is that the docs seem to be updated with work arounds and
suggestions that help a new developer get "unstuck" from Flask's design
decisions. Maybe a best practices section would be valuable where
problems found on the mailing list can be codified in the docs along
side recommendations for using the "cherrypy-*" packages I mentioned
above.
To summarize the above suggestions:
1. Take Sylvains examples and package up the database and templating
examples into "cherrypy-*" packages. Put them on Github and release
them to PyPI.
2. Add a best practices section in the docs that point to the
"cherrpy-*" packages and include any other obvious gotchas people
run into. Seeing as this would be an ongoing effort, copying many
of the recommendations in Sylvains example app would be an excellent
place to start iterating.
Hopefully these suggestions don't sound like a massive amount of
work. I'm happy to help setting up the "cherrypy-*" packages and getting
things like docs automatically building on read the docs and travis
working.
In my Flask app, where still ended up using CherryPy was as a standalone
server. Flask (and most wsgi frameworks) don't provide a production
ready server out of the box. Therefore, if you want to provide a single
command to run your app, you have to handle that aspect yourself. In my
use case, my package has two processes, a master and worker. The worker
needed to run a background thread that would ping the master with a
hearbeat when it started and send a "bye" message when it
exited. CherryPy made this extremely easy and convenient. A user of my
package can install it and immediately run either process using a single
command. This is a great feature!
Looking at the future of CherryPy, my suggestions above pertain
primarily to the "framework" portion. The CherryPy server could also use
some new features. It would be fantastic to allow starting more than one
process (a la Gunicorn) as well as allow for an "async" mode. The goal
is simply to reveal CherryPy as a valid option you can include in your
code, no matter the type of application. CherryPy immediately is
disregarded at times because it is a single process or because it can't
handle 10k connections. Implementing this, in addition to being
interesting, could be a great target for CherryPy 4 that would promote
using CherryPy with other micro-frameworks.
Obviously, the improvements to the CherryPy server are very "hand wavy",
so please don't assume these are required. We've used gevent with
CherryPy to improve performance over more connections, so that could be
one tactic on the async front. Allowing multiple processes along with
threadpools is somethng flup has done for a long, so it is definitely
possible. Of course, if no one is interested in implementing it, then it
most definitely won't happen. The point is that there are some concrete
improvements in the server that might not only garner new attention to
CherryPy, but could be fun code to write.
Generally, it feels like CherryPy could find a nice niche bring together
a web interface for a specialized service or daemon. Some services
require different server paradigms, so that is one direction to consider
taking CherryPy in the future.
Obviously, these are just my opinions. Sylvain, feel free to let me know
if it would be helpful to create packages for the example tools /
plugins and I'll dive in.
Obviously, this is all just my humble opinion!
Eric
Sent with my mu4e
nick...@gmail.com
Jan 7, 2015, 3:39:05 PM1/7/15
to cherryp...@googlegroups.com
I agree with what Eric said. CherryPy is extremely convenient as base for an easily installable standalone application with a web interface.
Generally, it feels like CherryPy could find a nice niche bring together
a web interface for a specialized service or daemon. Some services
require different server paradigms, so that is one direction to consider
taking CherryPy in the future.
To back that up a little, I can tell about me. I am making a generic MongoDB back end(with schema validation) that snaps nicely into CherryPy(will be at github in a couple of months).
And to back *that* up, I should mention that I, until recently, have spent fifteen years woking with insanely complicated RDBMS:es for financial systems.
I tried doing it in Tornado, but it was far more hassle and wouldn't work as well along my other functionality, so I went back to CherryPy(also Tornado sucks under Windows which I have to support as well).
True, there is functionality that others have and CherryPy don't, but I did a pretty thourough research before I started this project, and now I actually feel that many of those just aren't that important anymore.
Also, much in those frameworks is actually about simplify talking to RDBMS:es.
Take object-relational mapping and SQL generation for example; databases like MongoDB have practically exploded in recent years.
In those databases data is stored as documents, and those documents are basically objects already anyway.
No mapping or SQL stuff necessary, and I would think that 90 percent of application actually don't need a relational back end.
And to back *that* up, I should mention that I, until recently, have spent fifteen years woking with insanely complicated RDBMS:es for financial systems.
I would say that the importance of constant consistency is equally insanely overrated. Necessary almost only for that kind of applications.
So many things have moved from the server to the web client via angular and other frameworks, that heavy server side processing and deep structures aren't that important anymore.
Theming, for example...i fail to see that theming is a really important feature five years from now, you can do all those things on the client now.
So, yes, It is a niche, but I think that there are a lot of systems that work like that(semi standalone-web interface). There are gazillions of desktop applications that could work like that.
Anyway, around that back end I will make a BPM system. It won't need to handle thousand of connections per second, it is far more important with ease of use and maintenance..
So, yes, It is a niche, but I think that there are a lot of systems that work like that(semi standalone-web interface). There are gazillions of desktop applications that could work like that.
Anyway, around that back end I will make a BPM system. It won't need to handle thousand of connections per second, it is far more important with ease of use and maintenance..
So the reason I choose CherryPy was unparalleled simplicity, instability, nice structure and pythonicism. I think that has a broad appeal.
To come to a conclusion, I think that is the direction to take. Please don't try to be Django or whatever.
To come to a conclusion, I think that is the direction to take. Please don't try to be Django or whatever.
Refine and improve the things where CherryPy shines even further; making it even easier to get started and "sell" CherryPy as the perfect fit for a stand alone Python application.
Thanks a bunch for making CherryPy,
Nicklas
Nicklas
nick...@gmail.com
Jan 7, 2015, 4:08:02 PM1/7/15
to cherryp...@googlegroups.com
Sorry about the awful grammar and strange repetitions in the post..one should never write about important stuff while petting a cat. :-)
David Allouche
Jan 8, 2015, 8:32:31 AM1/8/15
to cherryp...@googlegroups.com
Since everybody appears to be chiming in with their perspective on Cherrypy, I'll throw in my two cents.
I use Cherrypy to run a subscription-based webapp that provides a "vertical" application for recruiters, helping them manage job applications and track candidates.
I inherited a technical base about 5 years ago, that included Cherrypy, and have been actively developing the software since that time. Many of our customers are using our web application as their primary work tool. So reliability and low latency are paramount. We have relatively low traffic, and we are only now starting to near the limits of the load that can be served with a single cherrypy server instance, constrained by the Python GIL bottleneck.
Therefore I need my dependencies to provide me a stable API, easy debugging when things go wrong, and the ability to solve any problem I might encounter with the minimal impact. I am explicitly NOT interested in shiny new trendy software. I want reliable boring old software that I can expect to be still maintained 5 or 10 years from now.
I had occasions to question most of the legacy in this application, but Cherrypy is one of the components that gave me the fewest problems. So sure, there are a few bugs, but most of the time I just silently work around them. Otherwise it let me pretty much do anything I want.
One of the "interesting" issues I needed to solve was convincing Cherrypy to play nice with zope.testbrowser, but that turned out to require only limited hackery. Had Cherrypy code been organised differently, that would have been much more difficult.
My biggest issue at the moment is the threaded server model means long-lived connections are a problem. In the past we had quality of service issues when one of the external services we relied on became unresponsive, so pending request accumulated, the thread pool filled up, and we stopped handling requests. In the future, we may want to use long lived http connections (javascript iframe, long polling, whatever) and the threaded server model might prove impractical.
My setup is a Apache front end that serves static assets (images, javascript, css) and forwards application page requests to the cherrypy web server through a mod_proxy reverse proxy.
Since the software architecture relies on some internal services in background threads, I plan to work around the GIL bottleneck by spawning multiple server processes and using 1. multiprocessing to let worker thread communicate with the internal services in the parent process 2. apache load balancing to spread the load on the server processes.
Recently, I was a able to add a caching decorator that used a WeakKeyDictionary keyed off cherrypy.serving.request, to provide thread-local, request-lived caching for some internal functions. It was a pleasantly easy thing to do.
In summary: Just keep it stable, sensible, and reliable. If you can, please leave to cool out.
Regards.
I use Cherrypy to run a subscription-based webapp that provides a "vertical" application for recruiters, helping them manage job applications and track candidates.
I inherited a technical base about 5 years ago, that included Cherrypy, and have been actively developing the software since that time. Many of our customers are using our web application as their primary work tool. So reliability and low latency are paramount. We have relatively low traffic, and we are only now starting to near the limits of the load that can be served with a single cherrypy server instance, constrained by the Python GIL bottleneck.
Therefore I need my dependencies to provide me a stable API, easy debugging when things go wrong, and the ability to solve any problem I might encounter with the minimal impact. I am explicitly NOT interested in shiny new trendy software. I want reliable boring old software that I can expect to be still maintained 5 or 10 years from now.
I had occasions to question most of the legacy in this application, but Cherrypy is one of the components that gave me the fewest problems. So sure, there are a few bugs, but most of the time I just silently work around them. Otherwise it let me pretty much do anything I want.
One of the "interesting" issues I needed to solve was convincing Cherrypy to play nice with zope.testbrowser, but that turned out to require only limited hackery. Had Cherrypy code been organised differently, that would have been much more difficult.
My biggest issue at the moment is the threaded server model means long-lived connections are a problem. In the past we had quality of service issues when one of the external services we relied on became unresponsive, so pending request accumulated, the thread pool filled up, and we stopped handling requests. In the future, we may want to use long lived http connections (javascript iframe, long polling, whatever) and the threaded server model might prove impractical.
My setup is a Apache front end that serves static assets (images, javascript, css) and forwards application page requests to the cherrypy web server through a mod_proxy reverse proxy.
Since the software architecture relies on some internal services in background threads, I plan to work around the GIL bottleneck by spawning multiple server processes and using 1. multiprocessing to let worker thread communicate with the internal services in the parent process 2. apache load balancing to spread the load on the server processes.
Recently, I was a able to add a caching decorator that used a WeakKeyDictionary keyed off cherrypy.serving.request, to provide thread-local, request-lived caching for some internal functions. It was a pleasantly easy thing to do.
In summary: Just keep it stable, sensible, and reliable. If you can, please leave to cool out.
Regards.
saaj
Jan 26, 2015, 2:08:35 PM1/26/15
to cherryp...@googlegroups.com
Hello CherryPy folks,
I've looked at the topics brought up in the thread by Sylvain and other.
It turned out to be lengthy, so if you prefer rendered reST, here's the link.
Basically this is a matter of opinion originating from my experience,
so it doesn't seek to be universally correct. Take it with the grain of salt if you like.
Acquisition
-----------
My CherryPy experience started in beginning of 2011. I had a chance to jump ship to Python
web application development and I didn’t lose it. At that moment I had years of web development
experience, so I was looking for the certain piece of software. If I would start this search
today, most of the front page titles are the same. The same *you don't have to be the best to
be popular* still applies to the very domain of Python application.
I've spent a couple of weeks reading the web: reviews, comparisons, benchmarks [4]_ and
StackOverflow [5]_. And I have to admit that there are paths for newcomers to CherryPy,
who look for stable, fast, well-designed and pythonic HTTP framework with its own Zen [6]_
(like Python itself [7]_), that doesn't dictate application design, nor what tools to use,
but rather provides structure, testability and primitives that help code scale.
Scope
-----
Where CherryPy stands? I think it perfectly stands as a Python HTTP application server. It
allows a developer to write a genuine Python code, use the best from the Cheese Shop,
design applications in whatever desired way (but with restrictions of threaded execution model).
Self-contained packages
~~~~~~~~~~~~~~~~~~~~~~~
I agree that stable pure-Python HTTP server is one of major features of CherryPy. Because
basically, in most cases one can just forget about WSGI, and use good old HTTP — bare CherryPy or
behind reverse-proxy like nginx. Less intermediaries means less problems as it simplifies
development and deployment. However, I don't think it's an additive feature. If you extract the
web-server into a stand-alone package, be it named Cheroot or something else, it won't be as
valuable for application development. If there are other frameworks' users who host their WSGI
applications with CherryPy, it's their problem of deployment and of these framework's authors.
This usage is ultimately a byproduct of CherryPy's WSGI compliance and stability, and let it
stay so.
On the other hand, as the questions risen in the post are mostly about the cost of CherryPy
maintenance, if the increased modularity will help to reduce it, then it surely makes sense.
But the extraction also has its cost, and if the code of target functionality is tightly coupled
with the rest of the codebase, then benefits of extraction should clearly outweigh its cost.
At least inner-package refactoring towards more encapsulated components is possible with
almost the same benefits.
Implementation support
~~~~~~~~~~~~~~~~~~~~~~
Regarding supported Python implementation official website says: *Python 2.5+, 3.1+, PyPy, Jython
and Android*. Documentation says: *CPython, IronPython, Jython and PyPy* and *CherryPy supports
Python 2.3 through to 3.4.*. There's no need to say about official distribution, CPython, but its
versions are in question. There's a lot of compatibility code for old Python versions in CherryPy,
which can be shrunk by lifting the bar closer to actual ones. I don't think the move is for 3.x
series, but for CherryPy 4, CPython 2.7 and 3.3+ are fine. This is a real way to make the codebase
cleaner, smaller and fun to deal with again.
PyPy is constantly taking more ground and is supported by many libraries that also grow in
number. However I can't get many real use-cases out of my head (if we don't actually include the
case of a long task which should be run in background, but is run synchronously as an effort
tradeoff and assuming it can benefit from JIT), nor do I know if there's CPU-bound hot CherryPy
code. Mostly I feel it's a cool-factor, but with possible real use-cases. So I think it's a good
idea to keep it. The problem with supporting PyPy is its garbage collectors. They aren't based on
reference counting, thus files, sockets and everything that was able to close itself passing out
of the execution scope with zero references on CPython, won't deterministically keep doing it on
PyPy. It makes more strict demands on code to keep it memory-leak free. Python3's
``ResourceWarning`` can help with it. I left a bug report [8]_ about the subject once when I was
porting a CherryPy-based library to Python3.
The rest is more questionable. CherryPy running on Android is clearly a cool-factor.
SL4A with Python isn't straightforward to install, and even though there's complete
CPython 2.6, it barely has a single real use-case. There's file API, SQLite and the rest
important things we use server-side for, for PhoneGap and the like, for ones who write HTML5
application. There's Kivy with established deployment. The same way I feel of Jython and
IronPython support. I have no idea if anyone is actually using CherryPy on them, but having them
officially supported complicates things. Testing, debugging, developing the framework. I think
these highly specific environments should be covered by enthusiasts, if there're any out there,
who deal with them. If there's a bug, say for Jython, it should be treated as enhancement and
fixed only if the fix doesn't impede design, performance and maintainability of primary
implementations' code. I think guarantees and according measures are needed, so it's clear
what is officially supported by CherryPy, and what it may run on.
To depend or not to
~~~~~~~~~~~~~~~~~~~
For an application it is perfectly fine to depend on as many libraries to delegate as most
out-of-domain functionality away from its codebase. On the other hand for a library it's not as
good idea. There's a functional difference between a library and a framework, but for current
form of CherryPy these terms feel interchangeable.
For a library having no dependencies is a feature when general *less moving parts, less issues*
applies. It may relate to broken, abandoned, license-changed 3rd-party dependencies. It may be
incompatible changes, or used C-modules which complicate installation and use in PyPy and other
implementations and platforms. Thus as CherryPy has grown its own pure-Python internals which
are fast and stable, I think there's no point in abandoning them.
Hype, fuss and choices
~~~~~~~~~~~~~~~~~~~~~~
Last, but not least thing I want to note about the scope of CherryPy is its technology choice.
WSGI is good example here. From inception it likely was a cool thing in Python. WSGI here
and WSGI there, standards, uniformity and stuff. And then, a little later... oops, a synchronous
protocol. No WebSockets, no SSE, no other close to real-time techniques. This choice affects, for
example things like django-sse [9]_ and its users [10]_ (though this community is strongest in
seeing everything as a nail). But also PaaS providers like OpenShift [11]_, and probably others.
That is to say it's okay to be compliant (e.g. WSGI-compliant), but it's not okay to be a pliable
bigot, who praises next cool X at every turn. In that sense I like how CherryPy stands. Simple is
simple in a threaded server. Real-time stuff needed? Sylvain's ws4py [12]_ to the rescue.
Simple background processing? There you go with ``cherrypy.process.plugins.BackgroundTask``.
So I want to keep seeing CherryPy making conscious and pragmatic technology choices.
2014 has seen new breed of asynchronous libraries within Python 3.4+ batteries, ``asyncio``. It
is nice to see co-operative execution in Python finds more expressive language constructs and
tooling, but apart from its niche uses I suspect it'll be next asynchronicity-everywhere craze,
which will lead to rewrites, new cool stuff and more "pressure" on users of "old" software. At
least, there's no evidence that it can be faster on generic load, as CherryPy is neck and neck
with Tornado [4]_. There's good socket performance notice [13]_ in Python documentation which
also applies generally to such design choice.
There’s no question that the fastest sockets code uses non-blocking sockets and select to
multiplex them. You can put together something that will saturate a LAN connection without
putting any strain on the CPU. The trouble is that an app written this way can’t do much
of anything else - it needs to be ready to shuffle bytes around at all times.
...
Finally, remember that even though blocking sockets are somewhat slower than non-blocking,
in many cases they are the “right” solution. After all, if your app is driven by the data
it receives over a socket, there’s not much sense in complicating the logic just so your
app can wait on ``select`` instead of ``recv``.
Audience
--------
Naturally appreciation comes from the target audience. For a newbie in HTTP (which is a
complex protocol by the way) and application development in general, Django may be a blessed
gift because it helps to meet her goals by answering as many development questions as possible,
and at the same time for an experienced developer it may seem a worthless bulk of bloatware
that solves all its tasks equally poor (like all generic solutions, though). The same newbie
won't be able to effectively use CherryPy because it won't answer the several dozen of questions
for her.
If CherryPy stays CherryPy there can't and shoundn't be answers for many of them. How to design
my application? What application directory layout to use? What persistance layer and storage to
employ? How do I render a template in CherryPy? It's all up to you, developer. From my
experience, reading others' opinions on the web, and particularly in the user group, there is
an unanimously opinion that CherryPy's barrier to entry is high, but once you wrapped your head
around its concepts you're enlightened and empowered.
These points lead to two measures of increasing CherryPy user base, and hopefully contributors at
some proportional rate. First is targeting more specific audience. Examining the main page [1]_ it
is at least not bad. It shows that simple is easy, and gives clues that complex is possible. It
refers to *any other object-oriented Python program*, which indicates good API. But it's biased
opinion, because I look at things in reverse. Is it really that comprehensible for one who is
making decision at the moment? Is there some real-world CherryPy code that is widely
considered worth exposing, that is done "right" way and promotes best CherryPy practices? Second
is means of lowering and alleviating barrier to entry, see `Improvement`_ section.
A note about code hosting that is supposed to affect the audience. I agree with Konstantin
Molchanov, that magic pixies... wait no, the best friend of Ruby and Rails, to the backbone
awesome, the octocat won't make CherryPy popular by the wave of its tentacle. There's no outreach
program nor there's traffic charity for newcomers on Github. It's a popular code hosting which
makes it easy to contribute to a Git repository, in case there're ones who are willing to. But
if there are no new contributors, I don't see the way it can help.
Though it may not work in opposite direction, because if there's a Python developer willing to
contribute to a Python project, the developer may expect a Python tool for it, which Git is not.
I think it's a disillusioned and naive idea to turn away from Mercurial to get more Python users.
At the same time, I cannot disagree with Nic Young that there're a few developer services (mostly
for quality assurance) which integrate only with Github, which are free for open source projects
and may be useful for CherryPy (e.g. TravisCI is not Git-only, but Github-only because it's tied
to its API), albeit none of them lack alternatives.
Part taken
----------
A year after I commenced my CherryPy affair one web application project was in production and I
possessed certain portion of experience. Specifically saying, deployment struggle experience.
Having HTTP-only deployment was very helpful, because I could reuse the knowledge I had, but Linux
part was at most scarce, poorly covered and I was groping for valuable pieces of knowledge all
over the web. Having mint Debian box how do I make my application continuously deployable? How do
I make it first-class daemon and run it as *www-data*? How do I put it behind nginx? How do I
monitor its memory and CPU usage? How to restart it if it has crashed? How do I rotate its logs?
That time I already had the answers, and they were put together and published as tutorial/skeleton
project [14]_. I felt it was necessary contribution to make. Obviously, it hasn't received high
volume traffic, but qualitatively there're constant visits from all over the world (and least from
the countries where people do IT), which indicates that CherryPy still attracts new users.
In mid-2013 I've written another tutorial/skeleton project [15]_, and even though its goal
is maintainable JavaScript website-like application design, its server-side is CherryPy
application with real-world template layout for Jina2 and according CherryPy tool. I've found
time to write documentation for it only in the end of 2014, so it is also an on topic thing.
In the spring of 2014 I started to participate on StackOverflow's CherryPy tag [5]_. It was
another pay-off kind of thing, because the site was helpful to me, and its CherryPy part
specifically. But the latter sadly had a lot of unanswered question making it feel a little
abandoned. In fact many questions are quite interesting dealing with performance, design,
execution model of CherryPy, so it requires an answerer to have a good grasp of documentation and
codebase. Besides making other users' CherryPy experience better, it is fun and cognitive
activity. It sheds the light on how people really use CherryPy, how they start, where are
remaining rough edges and what is the room for improvement.
Improvement
-----------
Inherently I'm an application guy. I pick out cog-wheels, tune them and make spin together. I
don't work on a library oftentimes, nor do I have much time for it, but because I really value
CherryPy I want to have a way to do it, in case I have time and idea for improvement or fix. For
instance, I want to add privilege drop plugin to ``cherryd`` and make other minor improvement to
it.
When you file a bug report, you generally expect someone, a core contributor or so, to tell you
whether it is generally valid or not. Then it may be re-prioritized, assigned to someone or put
on a shelf to wait its day. Without this initial input it's a little confusing. "Okay, no one
replied. It should be working other way", — you may think, at best.
Understanding the flow of one's patch to CherryPy codebase is also important. Official site says
*fork CherryPy on BitBucket here and submit pull-request with your modifications*. When it's a bug
either when it's an enhancement? Who and where to ask a flow question, say about branching, or
about eligibility of a change. There's ``CONTRIBUTING.txt`` which didn't appear long ago and it
points to Jason Coombs' post [17]_ about writing a perfect pull request. It is at least something
but I think it can be more clear and CherryPy-specific. Also I think it should in the
documentation, linked from the website's main page.
Quality assurance
~~~~~~~~~~~~~~~~~
I think things like bug #1298 [16]_ should never happen to a project which is maintained in
a responsible way and puts effort in quality assurance. Okay, I see ``tox.ini`` in root of the
project. I clone it, and run ``tox``. Duh, all environments have failed. Besides, not all the
claimed environments are in the file. Moreover, it's some kind of back in Soviet Russia story.
Why the hell unit tests ask me questions!? Are they examining me instead? More surprises?
ShiningPanda is dead [18]_, the same way as the link to it from the CherryPy website under
*online tests* section (*continuous integration* is kind of standard term for the thing, as
online tests refer more to IQ tests, psychology, et cetera).
To name it honestly, this is a reckless way of maintaining a project. Reckless to users whose
applications will break with next release published this way. And *interpretation result* is
as much time-consuming as to see whether the build page is green or red. No, I'm not promoting
these cool badges one can see all around. I'm talking about the responsive flow where every
contributor runs tests on all supported Python implementations (with Tox) before pushing her
changes. If one is lazy to care and to set up all implementations, but has itching fingers to
push some changes anyway, having the notification like: *Hey, you've just broken CherryPy. Please
fix ASAP* would be helpful. I think for everyone who has write permission to the repository it
makes sense to receive such notification. At very least the one who publishes CherryPy to the
Cheese Shop should have rigid requirement to check CI page.
The same concern, with lesser strain, applies to the ReadTheDocs builds, which all have failed
for last 3 months [19]_.
This is the problem which needs to be solved as soon as possible. In 2014 I tried the CI service
called Drone.io, which supports the three major code hosing services. Well, it turned out to be
usable (build page example [20]_). I can help assist or set it up for CherryPy, once flow and
role questions are answered.
Barrier to entry
~~~~~~~~~~~~~~~~
Hopefully, one of biggest barriers I was facing myself seems to have passed. I mean that
documentation link erosion where almost every single CherryPy-related link on the web leaded
to 404 page. I think ReadTheDocs adoption is huge improvement, especially considering that new
documentation, being clearly a better one, lacks some details that were covered in version 3.3.
Having persistent, versioned and indexable documentation is very helpful.
I think, it should be stated more or less directly that if one wants a framework to
make application design decisions it's better off using something else, not CherryPy. Okay,
here's Joe who knows enough about Python. He's conscious and is willing to make application design
decisions and take responsibility for them. But he also has a deadline. Joe doesn't expect his
first real-world CherryPy application to be shiny from experienced CherryPy developer point of
view, albeit functional from end-user's. What's the best way to help Joe create functional
prototype quickly, and let him gradually improve the design and codebase of his application
thereafter, along with CherryPy knowledge?
Let's look at CherryPy knowledge as a tree. Each branch represents a functionality. Say a CherryPy
tool branch. As it goes from the root, there're nodes like *Copy-paste this decorator to turn your
handler result into JSON*, *What other tools are capable of?*, *What is a CherryPy tool, and how
to write one?*, *Tool hook-points, types, priorities, etc.*. The same is for other branches —
from basic to advanced. And what will Joe benefit from the most is breadth-first traversing on the
tree. Better if some of a few first levels are illustrated with runnable snippets. This way it's
possible to give overview, tunable blocks of code and directions for improvement. For the later is
important to spur creativity, but not enforcing design decisions, in the way: *start with this,
improve by yourself*.
I've just glanced over the latest documentation over again, and surprise, it narrates in very
similar fashion! Sylvain has done a great job. But what is catching my eye is that there's two
separate tutorial series now: one in the source code [21]_, another in the documentation [22]_.
Even though both serve the same purpose, the former is much easier to maintain, covering with
tests which leads to the bonus of better regression test suite. If the later's textual flexibility
can be sacrificed for less maintenance cost, I think, it's possible to generate tutorial section
from module docstrings and code, and merge the two.
However, both series deal with simplest cases and there's a big gap between them and real-world
application requirements. Here I also a snippet to base on directly or get ideas from to
get a prototype faster, but with real-world tools. Like safe database access in threaded
environment, URL routing and generation, multi-allplication design and so on. Sylvain's CherryPy
recipes [23]_ referred in the documentation several times may answer this to some extent, but in
general I think it's still in question. But also whether it should maintained in centralized
fashion within CherryPy. Or if it's more suitable for external source, like post on somebody's
blog or StackOverflow.
Contribution packages
~~~~~~~~~~~~~~~~~~~~~
I think Eric Larson's suggestion about ``cherrypy-*`` pageages makes sense. For example there's
a package called cherrys [24]_ which is the good example. It's a Redis adapter for
CherryPy session handling. What's important it has clearly defined scope and doesn't affect
an application design. This way it might have been named ``cherrypy-redis-session``.
A package that is an implementaion of an CherryPy interface must be appropriate for packaging and
sharing. Sharing a CherryPy application with clearly defined scope, like Dowser [25]_, is
also beneficial.
On the contrary specific tools or plugins that affect application design shouldn't be packaged.
For instance, looking at Sylvain's recipes they are all better to say recipes. Let's look
at Jinja2 recipe [26]_. Besides having a class per file isn't pythonic, and splitting a thing
into plugin and tool isn't always rewarding, it makes certian assumtion on how template file
names are defined for the URL. Jina2 is a flexible template engine with notion of template
inheritance. Real-world projects have dozens of templates and tend to orgianize them by role
and use. Having some convention-over-configuration rule for template name is very handy.
So I want to say it's usually better to have a small and effiective application-specific
CherryPy tool or plugin rather than trying to invent something overly broad and generic one.
Other changes
~~~~~~~~~~~~~
Bitbucket pages should have either actual supplementing information or no supplementing
information. Menu community link [27]_ leads to wiki home page where version section has latest
version of 3.2.5. Menu development link [28]_, which points to the repository overview page refers
to Python 2.3, where the site's version starts with 2.5+. Referring ``python setup.py install`` as
installation command, which requires a manual download, ought to be changed to normal
``pip install cherrypy``.
I think, minor changes on the website are needed:
* no need in download link in the menu,
* add *install* section after *features* which says ``pip install cherrypy``,
* community link is better to refer to the user group,
* rename *online tests*, change the service link, use better sentence which will emphasize
reliability.
About ``_cp`` module prefix. There're some public classes like ``cherrypy._cptools.HandlerTool``,
which may be used in user code directly or as super classes. This isn't correct naming, according
to the underscore convention. So it's a good idea to change it some day. Though as a PyDev user I
can't recall to any issues with it.
Wrap-up
-------
I can conclude that there're two things that I'm seeing problematic: quality assurance for various
claimed enviroments CherryPy to support and lack of contribution guiadance, specifically in the
form of bug tracker supervisor. The rest feels normal, if that makes sense and as it is usually
the case needs small constant improment and polishing.
____
.. [1] http://cherrypy.org/
.. [12] https://ws4py.readthedocs.org/
.. [26] https://bitbucket.org/Lawouach/cherrypy-recipes/src/tip/web/templating/jinja2_templating/?at=default
Regards,
saaj.
Sylvain Hellegouarch
Jan 27, 2015, 2:43:45 PM1/27/15
to cherryp...@googlegroups.com
Hello saaj,
Well... thank you very much for having put such a thorough response. Not that previous replies were lacking, but you did try to cover it all. Thanks a bunch.
I'd rather not go and respond to each point, this would probably become tedious to everyone. However, I believe the overall set of replies we had so far all agree on some ideas, in no particular order:
* package up some common helpers like Eric started doing. My recipes may be a good starting point but don't have to be packaged up as-is.
* clarify the contribution's process
* formalize the distribution process and get more strict about it
* fix what's broken: tests, nightly builds, doc build
* avoid dependencies
Some other points people which people don't quite agree on yet:
* moving to github
* renaming modules
* splitting up into packages
Overall, as Joel said early in this thread. It seems mostly about getting the project's management under control and avoiding letting it look dead. As you mention saaj, responding more on SO would be a great way to improve people's perception. Likewise, as Konstantin said, publishing to reddit would increase our audience probably.
On the management level, what I would like is for the folks with the credentials to speak up and let me know about it (Robert? Jacob?). We could then see to automate a few things and, perhaps, give more permissions to some willing users.
Cheers,
--
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.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages