Bug 224683 - cherrypy 3.0.0 is available
cherrypy 3.0.0 is available
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: python-cherrypy (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Luke Macken
Fedora Extras Quality Assurance
:
Depends On: 429007
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-26 19:01 EST by Nils Philippsen
Modified: 2016-09-19 22:37 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2.3.0-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-02 04:01:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
First cut at a compat package spec file (2.78 KB, text/plain)
2007-08-29 15:13 EDT, Toshio Ernie Kuratomi
no flags Details
Minor cleanups (3.03 KB, text/x-rpm-spec)
2007-09-01 00:36 EDT, Toshio Ernie Kuratomi
no flags Details
Update to python-cherrypy.spec for 0.3 (2.53 KB, text/x-rpm-spec)
2007-09-01 00:37 EDT, Toshio Ernie Kuratomi
no flags Details
Setuptools patch (1.88 KB, patch)
2007-09-01 18:35 EDT, Toshio Ernie Kuratomi
no flags Details | Diff

  None (edit)
Description Nils Philippsen 2007-01-26 19:01:54 EST
upstream has new version 3.0.0, it was released on 2006-12-23
Comment 1 Luke Macken 2007-04-23 11:09:42 EDT
We've been hesitating to bump CherryPy because the current version of TurboGears
does not work with v3.0.  TG 1.0.2 should be coming out next week, so I'll be
pulling CherryPy 3.0 in shortly.
Comment 2 Robert Spanton 2007-06-07 12:25:25 EDT
Now that TurboGears 1.0.2 is out, this is no longer a barrier to CherryPy 3.
Comment 3 Luke Macken 2007-06-28 14:46:06 EDT
TurboGears 1.0.2.2 does not yet support CherryPy 3.
Comment 4 Luke Macken 2007-06-28 20:14:06 EDT
15:14 #turbogears:  Lawouach> lmacken: from what I gathered I don't think the 
                              TG core team will focus on CP3 for TG2 and I 
                              doubt they'll spend much of their time on TG1.x
Comment 5 Nils Philippsen 2007-07-03 08:44:55 EDT
Hmm. Luke, do you think it is sensible to wait for TG to support CP3? If I
understand comment #4 correctly, the TG team doesn't plan to support CP3 with
TG2 either... which would be very unfortunate.

Perhaps we could package CP2 separately for TG, e.g. into a different tree and
extend sys.path so TG uses CP2 rather than CP3 if both are installed. What do
you think?
Comment 6 Luke Macken 2007-07-03 09:08:47 EDT
Yeah, it's definitely not sensible to wait for TG.

I was thinking we could either,
  - create python-cherrypy3 package, and keep python-cherrypy the 2.x branch
or
  - create python-cherrypy2 package, and keep python-cherrypy up to date with
latest (3.x for now)

Is there anything else we could / should do instead ?
What do you guys think?
Comment 7 Toshio Kuratomi 2007-07-03 10:52:56 EDT
The Packaging Guidelines currently want the latest version to have <packagename>
and earlier versions to have <packagename><majorversion>.  I'm trying to get
that relaxed in today's Packaging meeting so hopefully either one of these
packages, python-cherrypy3 or python-cherrypy2 will be fine.

What I'd suggest is playing around with eggs to see if we can parallel install a
python-cherrypy2 that turbogears can continue to use with import cherrypy.  I
think both python-cherrypy2 and python-cherrypy3 will need to be installed this
way in order to work.  (Installing one the "normal" way and the other as an egg
should allow us to escape filesystem conflicts but I think we need to use eggs
for both so that setuptools can decide which module version is to be used.)

I can help get the Packaging Guidelines changed to accomodate eggs as well.
Comment 8 Toshio Kuratomi 2007-07-03 11:40:33 EDT
I've started a packaging draft to add to as we figure out how to use eggs to our
advantage:  http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs
Comment 9 Luke Macken 2007-08-16 22:05:28 EDT
Hey Ignacio, do you have any suggestions for supporting parallel installs of
CherryPy{2,3} ?
Comment 10 Ignacio Vazquez-Abrams 2007-08-16 22:47:39 EDT
Well, the way I see it we have 2 options for supporting parallel installs.

The first is to rename one of the packages. We would need to e.g. rename the
package in cherrypy 2.x to cherrypy2, then modify all scripts that currently use
cherrypy 2.x to use it. It's not pretty, but it would certainly work.

The second is to use alternatives, with either eggs or renamed packages. I get
nauseous just thinking about this option, but it is there.

There is, of course, a third option. We could forgo supporting parallel installs
entirely and just have the 2 packages conflict. While not a perfect solution, it
may be the best.
Comment 11 Toshio Ernie Kuratomi 2007-08-17 13:00:34 EDT
(In reply to comment #10)
> Well, the way I see it we have 2 options for supporting parallel installs.
>
Really?  I thought that this: 
  http://peak.telecommunity.com/DevCenter/PythonEggs#using-eggs

meant that you could have two eggs of different versions on the system and then
use this:
  http://peak.telecommunity.com/DevCenter/PythonEggs#automatic-discovery
to constrain the version.  No need for alternatives or renaming the modules.

Note that this is all book learning, I haven't played with actual eggs to see if
this is true, just that reading the docs seems to imply this.  If I'm wrong just
point out my error so I can stop thinking that eggs will solve this problem :-)
Comment 12 Ignacio Vazquez-Abrams 2007-08-17 13:05:07 EDT
(In reply to comment #11)
> Really?  I thought that this: 
>   http://peak.telecommunity.com/DevCenter/PythonEggs#using-eggs
> 
> meant that you could have two eggs of different versions on the system and then
> use this:
>   http://peak.telecommunity.com/DevCenter/PythonEggs#automatic-discovery
> to constrain the version.  No need for alternatives or renaming the modules.

But what if someone says "import cherrypy"? Which version does that load? 3? But
what if 3 isn't installed?
Comment 13 Toshio Ernie Kuratomi 2007-08-20 14:47:18 EDT
I'd say that the main package (usu. the latest version) would be imported from
import cherrypy.  The cherrypy2 package will be treated as a compat package. 
(Should it be named compat-python-cherrypy2?)

If the main package isn't installed then a bare import cherrypy will not work. 
pkg_resources will have to be used.  Packages wanting to select a specific older
version of cherrypy will have to use the pkg_resource API to select the older
version anyway...

Does this sound reasonable?
Comment 14 Toshio Ernie Kuratomi 2007-08-29 15:13:06 EDT
Created attachment 179621 [details]
First cut at a compat package spec file

I created this to test out the proposed Python Egg/python module compat
guidelines.
Comment 15 Toshio Ernie Kuratomi 2007-09-01 00:36:35 EDT
Created attachment 184281 [details]
Minor cleanups

Here's some minor cleanups to the spec for a new cherrypy2 package.
Comment 16 Toshio Ernie Kuratomi 2007-09-01 00:37:51 EDT
Created attachment 184301 [details]
Update to python-cherrypy.spec for 0.3

Here's a python-cherrypy.spec updated to 3.0
Comment 17 Toshio Ernie Kuratomi 2007-09-01 00:51:35 EDT
Those two spec files parallel install cherrypy with the following characteristics:

1) python-cherrypy is installed such that import cherrypy imports it.
2) python-cherrypy2 is available by doing::
  import pkg_resources
  pkg_resources.require('cherrypy < 3.0beta1')
  import cherrypy
3) Since cherrypy does not use setuptools or provide eggs by default these
packages don't provide eggs in the default branch.  This means that you cannot
use pkg_resources to load cherrypy3.

These mostly follow the draft guidelines posted on::
  http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs

The only thing I know is wrong is that I forgot to write and include a
README.fedora for python-cherrypy2 that explains it is as compat package and how
to  use pkg_resources.

If you think the draft has issues, please get back to me before Tuesday next
week (when the packaging committee will talk about them and vote.)
Comment 18 Luke Macken 2007-09-01 01:45:49 EDT
Looks good to me.

The only thing that requires cherrypy2 is TurboGears, and we currently patch the
"CherryPy >= 2.2.1,<3.0.0alpha" out of our setup.py.  So, theoretically if we
leave that in there, we should be good to go ?
Comment 19 Toshio Ernie Kuratomi 2007-09-01 02:28:16 EDT
Theoretically.  Of course I'm trying to get it working now and it's having
difficulties.  TurboGears needs to find eggs for the packages listed in
requires.txt but it seems that it doesn't do the equivalent of
pkg_resources.requires() on them so we are getting the cherrypy3 version instead
of cherrypy2.

I'm looking at the pkg_resources code right now to see if I can find the problem.
Comment 20 Toshio Ernie Kuratomi 2007-09-01 18:35:11 EDT
Created attachment 184641 [details]
Setuptools patch

I sent this to the distutils list and setuptools maintainer to look over.  Once
they let us know if some version of it can go into seutptools, I'll try to get
it applied to our setuptools package.  Parallel install works with this and
with the CherryPy requirement in TurboGears added back in.  We also need to set
a maximum version on the SQLAlchemy requirement:
  SQLAlchemy>=0.3,<0.4.0beta1

And get the python-sqlalchemy0.3 package reviewed.
Comment 21 Toshio Ernie Kuratomi 2007-09-27 19:35:56 EDT
I think all our ducks are lined up now.
* Egg Guidelines have been approved
* setuptools has been upgraded in F-8.
* We have a method for making TurboGears start-APP.py scripts use the compat
modules.

Since we're currently in freeze for F-8 we need to decide whether we'll be doing
this as an F-8 update after initial release or for F-9 only.
Comment 22 Nils Philippsen 2007-09-28 04:19:44 EDT
(In reply to comment #21)

> Since we're currently in freeze for F-8 we need to decide whether we'll be doing
> this as an F-8 update after initial release or for F-9 only.

As TG is AFAIK the only component relying on cherrypy (and I guess it works),
perhaps you should check with release engineering whether an exception can be
made to get cherrypy3 into F8 proper. A zero day update from 2.x to 3 doesn't
make much sense...
Comment 23 Till Maas 2008-01-05 09:18:11 EST
still not fixed in Fedora 7, 8 or rawhide :-/
Comment 24 Matt Thompson 2008-01-16 07:34:11 EST
I'd also like to add my hope for this bug.  A program I use (which I'd love in
Fedora 8) called rdiff-web:

http://www.rdiffweb.org/wiki/index.php?title=Main_Page

is now blocked by this as they don't support CherryPy 2.x anymore.
Comment 25 Matt Thompson 2008-01-16 07:35:39 EST
(In reply to comment #24)
> I'd also like to add my hope for this bug.  A program I use (which I'd love in
> Fedora 8) called rdiff-web:
> 
> http://www.rdiffweb.org/wiki/index.php?title=Main_Page
> 
> is now blocked by this as they don't support CherryPy 2.x anymore.

I should add it's the "testing" version of rdiff-web, but there are many
improvements in the testing branch that I might need.
Comment 26 Till Maas 2008-01-16 08:02:17 EST
(In reply to comment #24)

> is now blocked by this as they don't support CherryPy 2.x anymore.

Also I got cherrypy with fastcgi using python-flup only with cherrypy 3 working.
I do not know, whether using the old cherrypy works, but with version 3 it
worked like it was documented.
Comment 27 Toshio Ernie Kuratomi 2008-01-16 13:00:24 EST
I've got a suggestion:

I need to submit a python-cherrypy2 package so we can move to cherrypy3 on
rawhide but that's not going to help people get their packages running on F7/8.
 What does everyone think of a python-cherrypy3 package for F8(possibly F7)? 
Good idea?

I'll submit my python-cherrypy2 package for review so that you have a spec file
to base off of.  The maintainers of python-cherrypy3 should probably sign up as
comaintainers of python-cherrypy and vice versa so we're all in the loop.
Comment 28 Toshio Ernie Kuratomi 2008-01-16 14:08:11 EST
python-cherrypy2 compat package for rawhide has been submitted::
  https://bugzilla.redhat.com/show_bug.cgi?id=429007

If someone wants to help review and test that, it will help move this along in
rawhide.  If someone wants to adapt the spec for a python-cherrypy3 package for
F8, I can help review that.
Comment 29 Toshio Ernie Kuratomi 2008-01-21 17:14:01 EST
The review in #429007 has been completed.  Changes to update python-cherrypy in
rawhide and the python-cherrypy2 compat package are checked into cvs.  I'll wait
until tomorrow to build them so as to avoid breaking things just in time for the
alpha release.  If you want to get an early start on testing, download the
packages from http://toshio.fedorapeople.org/packages/

The relevant packages are
http://toshio.fedorapeople.org/packages/python-cherrypy-3.0.3-1.fc9.noarch.rpm
http://toshio.fedorapeople.org/packages/python-cherrypy2-2.3.0-3.fc9.noarch.rpm

We need to confirm that the two packages can coexist with CP3 being the default
and TurboGears using the CP2 package.
Comment 30 Toshio Ernie Kuratomi 2008-01-22 17:13:20 EST
Rawhide packages built::
  python-cherrypy2-2: http://koji.fedoraproject.org/koji/buildinfo?buildID=32491
  python-cherrypy-3: http://koji.fedoraproject.org/koji/buildinfo?buildID=32492

Brief testing shows that we're able to select between the versions as expected
in the python shell.  The ipython shell doesn't work, however.  It must be
overriding the standard import somehow....

Once we restore this line in the rawhide TurboGears setup.py file, TurboGears
apps will run as well:
  "CherryPy >= 2.2.1,<3.0.0alpha",

I'll leave this bug open until that change is made but otherwise I think we're
about done.
Comment 31 Fedora Update System 2008-01-24 16:47:57 EST
python-cherrypy-2.3.0-3.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python-cherrypy'
Comment 32 Fedora Update System 2008-01-24 17:01:02 EST
python-cherrypy-2.3.0-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update python-cherrypy'
Comment 33 Fedora Update System 2008-02-02 04:01:35 EST
python-cherrypy-2.3.0-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 34 Fedora Update System 2008-02-02 04:02:30 EST
python-cherrypy-2.3.0-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.