upstream has new version 3.0.0, it was released on 2006-12-23
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.
Now that TurboGears 1.0.2 is out, this is no longer a barrier to CherryPy 3.
TurboGears 1.0.2.2 does not yet support CherryPy 3.
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
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?
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?
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.
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
Hey Ignacio, do you have any suggestions for supporting parallel installs of CherryPy{2,3} ?
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.
(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 :-)
(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?
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?
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.
Created attachment 184281 [details] Minor cleanups Here's some minor cleanups to the spec for a new cherrypy2 package.
Created attachment 184301 [details] Update to python-cherrypy.spec for 0.3 Here's a python-cherrypy.spec updated to 3.0
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.)
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 ?
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.
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.
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.
(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...
still not fixed in Fedora 7, 8 or rawhide :-/
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.
(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.
(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.
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.
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.
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.
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.
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'
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'
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.
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.