Re: [Repoze-dev] Repackaged PIL 1.1.7
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Hanno Schlichting wrote: The confusion surrounding PIL almost makes me want to write some sort of über document listing the orginal problem along with all the various hack-arounds. Both of these show you the exact problem the official distribution has with setuptools. It uses a package name of '', How'd you figure that? Line 48 and 480 of PIL 1.1.7's setup.py would suggest it uses a package name of PIL... As this is a repackaging of a specific version of PIL, it needs to be done again for each new release. So far we only had a repackaging of the 1.1.6 version, I contributed one for 1.1.7 now. I would hazard a guess that none of the above are needed anymore ;-) You would be wrong, as you would know if you had tried running the effbot's packages inside an eggified environment: he is actively hostile to changes which would make this all go away, which leaves us with the necessity of forking his release. ch...@server2:~$ python virtualenv.py --no-site-packages test_pil New python executable in test_pil/bin/python Installing setuptools.done. ch...@server2:~$ cd test_pil/ ch...@server2:~/test_pil$ source bin/activate (test_pil)ch...@server2:~/test_pil$ easy_install PIL snip Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /tmp/easy_install-e9Tqhd/PIL-1.1.7/egg-dist-tmp-wuELlI WARNING: '' not a valid package name; please use only.-separated package names in setup.py Finished processing dependencies for PIL (test_pil)ch...@server2:~/test_pil$ python snip import Image Image.__file__ '/home/chris/test_pil/lib/python2.4/site-packages/PIL-1.1.7-py2.4-linux-i686.egg/Image.pyc' Yeah, the warning is a wart, but what's the problem? Has anyone tried asking Fred politely before? I did this a while back about the name of the distribution file and he was happy to change it to make things work for setuptools. What's he's not happy about is people ranting at him about a tool he doesn't use or care about ;-) I dunno if changing the package name is going to be an easy thing for him to do.. cheers, Chris ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On Fri, Apr 16, 2010 at 1:18 PM, Chris Withers ch...@simplistix.co.uk wrote: Yeah, the warning is a wart, but what's the problem? The problem is that installing his tarball with setuptools puts everything at the top level. import ImageFile works, but import PIL or any from PIL import ImageFile doesn't. All the code I have in any project uses imports from the PIL package. If you install the official PIL via it's normal setup.py without any setuptools involved, both incantations work. So you can do both import ImageFile and from PIL import ImageFile pointing to the same module. Thanks to pth file magic at work. setuptools doesn't do this kind of double installation, but sticks everything in one place. That place is either the top-level with the official distribution or the PIL package with the repackaged versions. In order for all my code to work, I need things to be inside the package and none at the top-level, as that creates conflicts with other modules of the same name, like in Zope2. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: ch...@server2:~$ python virtualenv.py --no-site-packages test_pil New python executable in test_pil/bin/python Installing setuptools.done. ch...@server2:~$ cd test_pil/ ch...@server2:~/test_pil$ source bin/activate You do know that the 'activate' bit pollutes your shell environment, right? I use virtualenv daily, with dozens of them on my system at any one time, and *never* use activate. (test_pil)ch...@server2:~/test_pil$ easy_install PIL snip Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /tmp/easy_install-e9Tqhd/PIL-1.1.7/egg-dist-tmp-wuELlI WARNING: '' not a valid package name; please use only.-separated package names in setup.py Finished processing dependencies for PIL (test_pil)ch...@server2:~/test_pil$ python snip import Image Image.__file__ '/home/chris/test_pil/lib/python2.4/site-packages/PIL-1.1.7-py2.4-linux-i686.egg/Image.pyc' Yeah, the warning is a wart, but what's the problem? Has anyone tried asking Fred politely before? I did this a while back about the name of the distribution file and he was happy to change it to make things work for setuptools. What's he's not happy about is people ranting at him about a tool he doesn't use or care about ;-) He doesn't namespace his pacakge, which means that his module names clash. E.g.:: $ /opt/Python-2.6.5/bin/virtualenv --no-site-packages /tmp/PIL-bare New python executable in /tmp/PIL-bare/bin/python Installing setuptoolsdone. $ /tmp/PIL-bare/bin/python import PIL Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named PIL import Image Image.__file__ '/tmp/PIL-bare/lib/python2.6/site-packages/PIL-1.1.7-py2.6...' The repackagd versions put his modules in a PIL namespace: $ /opt/Python-2.6.5/bin/virtualenv --no-site-packages /tmp/PIL-ns New python executable in /tmp/PIL-ns/bin/python Installing setuptoolsdone. $ /tmp/PIL-ns/bin/easy_install \ -i http://dist.repoze.org/legacy/simple PIL ... Finished processing dependencies for PIL $ /tmp/PIL-ns/bin/python ,,, import Image Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named Image import PIL PIL.__file__ '/tmp/PIL-ns/lib/python2.6/site-packages/PIL-1.1.6-py2.6...' import PIL.Image I dunno if changing the package name is going to be an easy thing for him to do.. Easy or not doesn't matter: he flat refuses. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvIgzAACgkQ+gerLs4ltQ7VywCgjglSOMrd/dHf1QKAXN2PHGn5 7MgAoMJhSWdreBTcgMAaRnPN5/RGfGX4 =swOe -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On Apr 16, 2010, at 9:33 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: ch...@server2:~$ python virtualenv.py --no-site-packages test_pil New python executable in test_pil/bin/python Installing setuptools.done. ch...@server2:~$ cd test_pil/ ch...@server2:~/test_pil$ source bin/activate You do know that the 'activate' bit pollutes your shell environment, right? I use virtualenv daily, with dozens of them on my system at any one time, and *never* use activate. activate is a bit of a kludge, though it seems easy enough to just have multiple shells open if activate screws with certain tasks. I'm curious though, how do you switch virtualenvs? I can envision creating wrapper scripts that only pollute the environment for a single process (running it in a subshell or whatever), is that what you are doing? I have to admit I haven't used virtualenv a whole lot, so I'm interested in hearing what you seasoned old timers do ;^) -Casey ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Easy or not doesn't matter: he flat refuses. To play devil's advocate: Why don't we just fork PIL entirely? I appreciate that a 1.1.7 came out recently, but before that 1.1.6 lasted three years. I doubt it'd be hard to keep up with a fork. The advantage is that we could package it appropriately, release the new package on PYPI, and avoid all this confusion with names. We would need to come up with a new namespace (i.e. not PIL) and adjust our code in Plone and elsewhere to use this new namespace. But that's probably less work than having this debate every few months. Martin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Am 16.04.2010, 17:42 Uhr, schrieb Casey Duncan ca...@pandora.com: activate is a bit of a kludge, though it seems easy enough to just have multiple shells open if activate screws with certain tasks. I'm curious though, how do you switch virtualenvs? I can envision creating wrapper scripts that only pollute the environment for a single process (running it in a subshell or whatever), is that what you are doing? I have to admit I haven't used virtualenv a whole lot, so I'm interested in hearing what you seasoned old timers do ;^) I don't know if I count as an old timer but I've been seriously tripped up by activate. virtualenv just sets up local Python environment for a project. All you then need to remember is to run bin/pip, as opposed to pip to install stuff. So, you don't need to worry about closing the shell or wondering about any side-effects when you do something in the same shell a few days later. activate provides minimal additional convenience at the risk of considerable confusion. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Casey Duncan wrote: On Apr 16, 2010, at 9:33 AM, Tres Seaver wrote: You do know that the 'activate' bit pollutes your shell environment, right? I use virtualenv daily, with dozens of them on my system at any one time, and *never* use activate. activate is a bit of a kludge, though it seems easy enough to just have multiple shells open if activate screws with certain tasks. I'm curious though, how do you switch virtualenvs? I can envision creating wrapper scripts that only pollute the environment for a single process (running it in a subshell or whatever), is that what you are doing? I just type 'bin/easy_install' or 'bin/python' or '../../bin/python' or whatever (and command-line history means I don't type it all that often). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvIicwACgkQ+gerLs4ltQ5aJACeLXC6rpVHVgUZL8HwdLqIoHAs NbcAoJLVZ235LA38e9fHjtKFLqT3hkHy =OQHy -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Easy or not doesn't matter: he flat refuses. To play devil's advocate: Why don't we just fork PIL entirely? I appreciate that a 1.1.7 came out recently, but before that 1.1.6 lasted three years. I doubt it'd be hard to keep up with a fork. The advantage is that we could package it appropriately, release the new package on PYPI, and avoid all this confusion with names. We would need to come up with a new namespace (i.e. not PIL) and adjust our code in Plone and elsewhere to use this new namespace. But that's probably less work than having this debate every few months. You don't need to change the package name (the imports), just the distribution nname (the dependencies). Jim's 'PILwoTk' package already does this: http://download.zope.org/distribution/PILwoTk-1.1.6.4.tar.gz Maybe we should just renew the request to push PILwoTk to PyPI[1] and update our dependencies. [1] https://mail.zope.org/pipermail/zope-dev/2007-October/029968.html Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvIjC0ACgkQ+gerLs4ltQ61HgCg0ppsEK/Y3YCDHb5EWzl4lmK5 EMcAnjubj/q26EpQkYMUmdWLhVXgWPsW =OHMv -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
On 04/16/2010 10:12 AM, Tres Seaver wrote: Maybe we should just renew the request to push PILwoTk to PyPI[1] and update our dependencies. [1] https://mail.zope.org/pipermail/zope-dev/2007-October/029968.html +1, I only use PILwoTk and I'd rather get it from PyPI. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] GAE or other 'cloud' choices for bfg apps?
Hi Tim, On Thu, Apr 15, 2010 at 1:55 PM, Tim Hoffman zutes...@gmail.com wrote: Hi Iain I have a number of projects on app engine. Some using repoze.bfg (www.polytechnic.wa.edu.au (paid work), www.fishandlily.com.au (my small business)) and others just using zope.component and bobo (not public yet). We are using app engines persistence model which is simple and straight forward. (http://code.google.com/p/bfg-pages/ has some examples of implementing a very simple cms on bfg and appengine, it implements traversal over entities in the datastore as folders and content). I think bfg is a good fit with appengine. A couple of pointers, you are basically using the view, traversal, component registry mechanisms and not zodb/persistence (which isn't really core to bfg). We are not currently using chameleon but straight zpt with a custom bindings see the link above. You need to watch startup times so I am moving away from using zcml and using python to register things. Yes, start up time is something I've noticed too. Aside from not using zcml for component registration do you have any other pointers to help with that problem? Thanks in advance, Darryl Cousins The really big advantage of app engine as I see it, is not having to deal with the system platform (ie cpu's disk, memory, networks, etc..) app engine is purely a runtime and services. So if you have little in the way of IT admin support, it is a big win. You do have to make some concessions/design compromises to take into account the restrictions enforced by the platform. As for economics www.polytechnic.wa.edu.au gets about 7000 unique visitors a day, around 20,000-50,000 page views a day and we have billing enabled but rarely get over 50% of the free quota so it's currently not costing anything at the moment to run. Rgds T On Thu, Apr 15, 2010 at 7:46 AM, Iain Duncan iainduncanli...@gmail.com wrote: Hey all, I have an app that eventually is intended to be used as a subscriber service. I'm totally new to the cloud thing, wondering if experienced bfg'ers would like to weigh in with their experiences - what is your preferred cloud deployment for bfg apps? - what persistence mechanism gets used? Is there some kind of facade over the bigtable? How do you handle it? - what is your experience with using cloud deployment, do you think it's even worth it? thanks! Iain ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] GAE or other 'cloud' choices for bfg apps?
Hi, On Fri, Apr 16, 2010 at 21:52, Darryl Cousins darryljcous...@gmail.com wrote: Hi Tim, On Thu, Apr 15, 2010 at 1:55 PM, Tim Hoffman zutes...@gmail.com wrote: Hi Iain I have a number of projects on app engine. Some using repoze.bfg (www.polytechnic.wa.edu.au (paid work), www.fishandlily.com.au (my small business)) and others just using zope.component and bobo (not public yet). We are using app engines persistence model which is simple and straight forward. (http://code.google.com/p/bfg-pages/ has some examples of implementing a very simple cms on bfg and appengine, it implements traversal over entities in the datastore as folders and content). I think bfg is a good fit with appengine. A couple of pointers, you are basically using the view, traversal, component registry mechanisms and not zodb/persistence (which isn't really core to bfg). We are not currently using chameleon but straight zpt with a custom bindings see the link above. You need to watch startup times so I am moving away from using zcml and using python to register things. Yes, start up time is something I've noticed too. Aside from not using zcml for component registration do you have any other pointers to help with that problem? GAE caches your app for one minute, IIRC. Some Django folks use a cron job to ping the app every minute to keep it in cache, since Django is a monster when it comes to startup times. Something like: http://www.morkeleb.com/2009/12/16/appengine-grails-cron/ Attila ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Repackaged PIL 1.1.7
Hi Tres, On 17 April 2010 00:12, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Easy or not doesn't matter: he flat refuses. To play devil's advocate: Why don't we just fork PIL entirely? I appreciate that a 1.1.7 came out recently, but before that 1.1.6 lasted three years. I doubt it'd be hard to keep up with a fork. The advantage is that we could package it appropriately, release the new package on PYPI, and avoid all this confusion with names. We would need to come up with a new namespace (i.e. not PIL) and adjust our code in Plone and elsewhere to use this new namespace. But that's probably less work than having this debate every few months. You don't need to change the package name (the imports), just the distribution nname (the dependencies). Jim's 'PILwoTk' package already does this: http://download.zope.org/distribution/PILwoTk-1.1.6.4.tar.gz Maybe we should just renew the request to push PILwoTk to PyPI[1] and update our dependencies. [1] https://mail.zope.org/pipermail/zope-dev/2007-October/029968.html Except... if someone has PIL installed globally (e.g. via OS packages), won't these two conflict? And even then, we'd be left with the naming confusion and possibly a which PIL do you have type question that'll confuse newbies quite a lot. Martin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
