On 28 Mrz., 19:28, Christoph Zwerschke <[email protected]> wrote: > Am 28.03.2011 18:05 schrieb Jannico: > > > installing turbogears (1.5b2) on a Vista box (shame on me) with a > > "fresh and empty" Python2.6.6 with plain easy_install turbogears seems > > to install CherryPy3.2.0 for Python3: > > Does not happen for me on WinXP or Win7. Maybe you have Python 3 in your > Windows PATH before Python 2.6? I'm pretty sure TG does not do anything > wrong here.
Yeah, seems to be a CherryPy related problem (but the behaviour is obviously not very nice for Turbogears as well). No, there never was Python 3-something on the machine - only 2.5. To make sure, I tried it also with an emptied path. Same behaviour. Downloading http://download.cherrypy.org/cherrypy/3.2.0/CherryPy-3.2.0-py2.6.egg (watch it, IE/Vista may want to give it a .zip type, simply rename it to .egg) and easy_installing it does the job. Just in case someone wants to look closer into the (CherryPy) problem, here is the output of running easy_install on CherryPy and the results of some further inquiries: >c:\Python26\Scripts\easy_install.exe CherryPy Searching for CherryPy Reading http://pypi.python.org/simple/CherryPy/ ... Reading http://download.cherrypy.org/cherrypy/3.2.0/ Best match: CherryPy 3.2.0-py3 Downloading http://download.cherrypy.org/cherrypy/3.2.0/CherryPy-3.2.0-py3.win32.exe (WRONG again) Well, I am by no means a setuptools expert, but it might be that something in the above process does not work as it should. For example, can_add(self,dist) in pkg_resources.py (setuptools0.6c11, btw.) correctly rejects CherryPy-3.2.0-py3.1.egg from http://download.cherrypy.org/cherrypy/3.2.0/ but it adds happily CherryPy-3.2.0-py2.win32.exe AND CherryPy-3.2.0-py3.win32.exe (for both Distribution objects that are created while parsing the result of the above http-request, py_version is set to None by the parsing step, whereas above, py_version is set to 3.1, which induces the rejection) Finally,pkg_resources.py sorts the py3 distribution in _sort_dists in , somewhat "correctly" to the front of the "best match" list (I spare you the details). The "error" seems to happen in parse_bdist_wininst() in setuptools \package_index.py, which does not recognize the python version if presented with a name as given (the EGG_NAME RegExp in pkg_resources would recognize it, but this one is not applied to .exe files). Code snippet (I verified that it is indeed used ;): def parse_bdist_wininst(name): """Return (base,pyversion) or (None,None) for possible .exe name""" lower = name.lower() base, py_ver = None, None if lower.endswith('.exe'): if lower.endswith('.win32.exe'): base = name[:-10] elif lower.startswith('.win32-py',-16): py_ver = name[-7:-4] base = name[:-16] return base,py_ver In our case, only the base name is set, not the py_ver (which is used to initialize py_version in the Distribution object to be created). What, I think, would be required is to name CherryPy-3.2.0-py2.win32.exe and CherryPy-3.2.0-py3.win32.exe CherryPy-3.2.0.win32-py2.exe resp. CherryPy-3.2.0.win32-py3.exe (well, almost, since, as we can see above, this would not work, as our version is only one character in length, and not 3, as is expected by the code above - so even better (without changing setuptools) would be CherryPy-3.2.0.win32-py2.3.exe and CherryPy-3.2.0.win32-py3.0.exe or similar (with the minimum minor version that can be used). I am not sure if this is only a problem on Vista, perhaps it depends on the setuptools version used? (perhaps the naming convention for windows bdists have been modified - sorry, I haven't checked this one out). Well, in any case, it is not a TurboGears problem, and I can work with the solution given above anyway. So I'll start experimenting tomorrow ;) > > > Context: We have to decide pretty soon if we want to "port" a somewhat > > large application developed against TG1.0.x (x=9 nowadays, 3 at the > > start ;) to 1.5 (we like to stay with CP) before finally going online, > > but perhaps aiming at CP3.2 is a bit over-ambitious? > > That's definitely a good idea and it's really much simpler than moving > to TG 2. There have been some minor fixes against TG 1.5b2 so there will > be a TG 1.5b3 or TG 1.5rc1 release soon; maybe you want to wait for > that. I can also give you some support on the mailing list. > > > More specifically: would those of you using CP recommend to install > > 3.1.2 instead of the recently released 3.2 for experiments (and, > > finally and, hopefully soon, production)? > > I have migrated all of my TG 1 apps in production to TG 1.5 + CP 3.2 > already and everything is running smoothly. That sounds promising! Thanks very much for the encouraging feedback, Christoph (exactly what I had hoped to hear... ;) > > -- Christoph -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
