Re: [Repoze-dev] Repackaged PIL 1.1.7
Chris Withers wrote:
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.
I don't believe this to be the case, so I dropped Fred a mail.
Here's his response:
Fredrik Lundh wrote:
Hi Chris, thanks for the heads up.
Not sure what's going on here; PIL is traditionally installed in
site-packages/PIL so that everything is available as from PIL import
..., but with a pth file that adds that directory to the path so that
pre-package code still works (there are tons of such code out there).
It looks like the setup.py file achieves this as follows:
extra_path = PIL,
package_dir={: PIL},
packages=[],
where extra_path creates the pth file, and the package_dir stuff makes
sure distutils installs things under PIL and not PIL/PIL. Some quick
Googling indicates that setuptools' support for extra_path is spotty
(non-existent until 2006, limited since then), so maybe this is the
issue?
Could you persuade whoever's ranting about this to jump over to
image-sig and propose a patch that fixes whatever problem Plone is
having but preserves the old behaviour?
Is such a patch possible? If so, could someone do as Fred asks and do so
while resisting the temptation to be rude and further alienate the
maintainer of what is a fantastic package? (yeah, I know, rich coming
from me...)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
___
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 2010-04-26, Chris Withers ch...@simplistix.co.uk wrote:
I don't believe this to be the case, so I dropped Fred a mail.
Here's his response:
Fredrik Lundh wrote:
Hi Chris, thanks for the heads up.
Not sure what's going on here; PIL is traditionally installed in
site-packages/PIL so that everything is available as from PIL import
..., but with a pth file that adds that directory to the path so that
pre-package code still works (there are tons of such code out there).
It looks like the setup.py file achieves this as follows:
extra_path = PIL,
package_dir={: PIL},
packages=[],
where extra_path creates the pth file, and the package_dir stuff makes
sure distutils installs things under PIL and not PIL/PIL. Some quick
Googling indicates that setuptools' support for extra_path is spotty
(non-existent until 2006, limited since then), so maybe this is the
issue?
Could you persuade whoever's ranting about this to jump over to
image-sig and propose a patch that fixes whatever problem Plone is
having but preserves the old behaviour?
Is such a patch possible? If so, could someone do as Fred asks and do so
while resisting the temptation to be rude and further alienate the
maintainer of what is a fantastic package? (yeah, I know, rich coming
from me...)
Wow! Thanks Chris. That sounds like something we can work with. Not to speak
for Hanno, but maybe Hanno could provide such a patch ;-)
cheers,
Chris
--
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
___
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 2010-04-16, Martin Aspeli optilude+li...@gmail.com wrote: Easy or not doesn't matter: he flat refuses. To play devil's advocate: Why don't we just fork PIL entirely? +1. I think the distribute fork has proven that sometimes this is necessary, and that a fork like this can succeed. Here is a package that *should* just be a no brain dep (possibly with complications due to requiring a compiler, like Zope 2?) but instead has been the bane of everyone's existence for the paste 5+ years (assuming you are using Plone, or some other app that requires PIL). It's fine to say Oh well PILwoTK works, or the PIL that is located *here* work fine. for everyone that understands the issue. However, to solve this problem for real I think a fork is necessary. (Note: I don't know the PIL author personally, nor do I even know he or she's name. I can appreciate the stop bothering me I don't care argument, but if that is really the position of the author then we shouldn't even think twice about forking. Also note: this argument is very similar to PJ Eby's argument re: setuptools, IIRC. In the end, both setuptools and distribute received a lot of 'love' as a result of the fork.) 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. Count me in. 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. +1000. PIL2? visualize (for likeness to distribute)? envision? All are PyPI safe AFAICT. We'd also need someone to *actually do it* ;-) Martin -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
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] 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
Re: [Repoze-dev] Repackaged PIL 1.1.7
-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. 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 iEYEARECAAYFAkvDb3AACgkQ+gerLs4ltQ6FZQCfbHTFdFNuCv3q8QnT2A/pzoiO ffIAoMLP5cEnOJwNsNb8oVtaV720ixMz =nJeL -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
Hi Hanno, On 2010-04-10, Hanno Schlichting ha...@hannosch.eu wrote: Hi. I took the time and repackaged PIL 1.1.7 for distribute / setuptools based on Chris work for 1.1.6. There's a fork on bitbucket [1] with my changes. bitbucket is not behaving right now, so I put up a source dist on jarn.com [2]. In order to generate the manifest I used setuptools_hg which is now in setup_requires. I'm not sure that's the best way to do it, so if someone has a better idea, please speak up. After I get some positive feedback, I'll put this into the downloads section on bitbucket and would be happy to see it copied to the usual dist.* places :) w00t. :-) A couple questions: (1) Just curious have you seen any issues with PIL and Zope 2 along these lines: 04:45 wiggy argh, PIL 1.1.7 breaks Zope 06:42 aclark wiggy: how? 06:42 wiggy aclark: it includes an ImageFile module at toplevel 06:42 wiggy aclark: Zope2 has one as well 06:42 aclark ah 06:42 wiggy and if the PIL one is found first things go boom 06:43 aclark can you control the order? 06:43 wiggy nope 06:43 aclark seems to me I've used 1.1.7 w/Zope 2… 06:43 wiggy I suspect it's pretty much random 06:44 aclark interesting 06:44 wiggy try reordeing the paths in bin/instance (2) Why the repackaging? I was under the impression that 1.1.7 alreaded works with setuptools OOB, e.g.: acl...@alex-clarks-macbook-pro:~/Developer/ virtualenv pil-test New python executable in pil-test/bin/python Installing setuptoolsdone. acl...@alex-clarks-macbook-pro:~/Developer/ cd pil-test acl...@alex-clarks-macbook-pro:~/Developer/pil-test/ bin/pip install pil Downloading/unpacking pil Downloading PIL-1.1.7.tar.gz (506Kb): 506Kb downloaded Running setup.py egg_info for package pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py Installing collected packages: pil Running setup.py install for pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py WARNING: '' not a valid package name; please use only.-separated package names in setup.py --- using frameworks at /System/Library/Frameworks building '_imaging' extension … PIL 1.1.7 SETUP SUMMARY version 1.1.7 platform darwin 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] --- TKINTER support available --- JPEG support available --- ZLIB (PNG/ZIP) support available --- FREETYPE2 support available *** LITTLECMS support not available To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. changing mode of build/scripts-2.6/pilconvert.py from 644 to 755 changing mode of build/scripts-2.6/pildriver.py from 644 to 755 changing mode of build/scripts-2.6/pilfile.py from 644 to 755 changing mode of build/scripts-2.6/pilfont.py from 644 to 755 changing mode of build/scripts-2.6/pilprint.py from 644 to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilconvert.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pildriver.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfile.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilfont.py to 755 changing mode of /Users/aclark/Developer/pil-test/bin/pilprint.py to 755 Successfully installed pil 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. Alex Cheers, Hanno [1] http://bitbucket.org/hannosch/pil-117-distribute/ [2] http://dist.jarn.com/public/PIL-1.1.7-preview.tar.gz -- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin ___ 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 Sun, Apr 11, 2010 at 3:14 AM, Alex Clark acl...@aclark.net wrote: A couple questions: (1) Just curious have you seen any issues with PIL and Zope 2 along these lines: 04:45 wiggy argh, PIL 1.1.7 breaks Zope 06:42 aclark wiggy: how? 06:42 wiggy aclark: it includes an ImageFile module at toplevel [...] (2) Why the repackaging? I was under the impression that 1.1.7 alreaded works with setuptools OOB, e.g.: Running setup.py egg_info for package pil WARNING: '' not a valid package name; please use only.-separated package names in setup.py [...] 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 '', which causes all modules in the distribution to be installed into the top-level namespace, instead of installing them into a package called PIL. So instead of from PIL import ImageFile they become available as import ImageFile. PIL is a perfectly good user of distutils, but it's specific setup.py isn't compatible with setuptools or any tools based on that. All the repackaged tarballs use setuptools directly and install the modules correctly. There's two versions of this repackaging, which both do essentially the same. One retains the distribution name PIL and was done by Chris, the other one is called PILwoTk by Jim Fulton and does the same, but also disables the rarely used Tk support. 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. Hanno ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
