[Image-SIG] Pillow, the "friendly" PIL fork

[Alex Clark]

On 8/1/10 10:29 PM, in article 4C562DA3.8030508 at noaa.gov, "Christopher
Barker" <Chris.Barker at noaa.gov> wrote:

> Alex Clark wrote:
>> On 8/1/10 3:04 PM, in article 4C55C525.9090809 at noaa.gov, "Christopher
>> Barker" <Chris.Barker at noaa.gov> wrote:
>> 
>> Š
>>> Is packaging the only "issues" this fork is for?
>> 
>> Yes. In Plone-land we rely a great deal on packages on PyPI.
>> Buildout is a
>> tool (which my 'Plone site admin' book covers in great detail, FWIW) we use
>> exclusively to build Plone CMS applications.
> 
> couldn't you have "recipes" for buildout that does a little extra for
> certain packages -- like in this case, remove the PIL.pth file.

Maybe. But that breaks the paradigm of "easy to add packages to your
buildout". A recipe is a layer of abstraction that provides additional
functionality. Installing PIL should be part of the existing functionality
IMO.

> 
> Or maybe change the name of the Zope package named "Image", as Fredrik
> mentioned, PIL has been around a long time.

Maybe. But I'm not quite sure how that would work. Zope 2 has also been
around a long time… ~12 years I think?

> 
> But in any case, a fork seems like a lot of work for such a simple conflict!

If only it were a simple conflict. Like I said, this has been going on a
long time. And like Fredrik said, the approach from the Zope/Plone community
has not always been the most friendly. I'm trying to see if we can fix this
once and for all, in one way or another. I'm still hopeful we can come up
with a patch, but a fork that breaks backwards compatibility wouldn't be the
worst thing in the world IMO.


Alex


> 
> -Chris
> 
> 
> 
>> Using Buildout to install packages is more or less the equivalent of running
>> "easy_install SomePackage", only the result is an "instance" script with the
>> packages specified in the buildout packages added to the sys.path. E.g.:
>> 
>> 
>> #!/Users/aclark/Developer/python-buildout/python-2.4/bin/python2.4
>> 
>> import sys
>> sys.path[0:0] = [
>>   '/Users/aclark/Developer/eggs/Plone-3.3.5-py2.4.egg',
>>   '/Users/aclark/Developer/eggs/Pillow-1.1-py2.4-macosx-10.6-i386.egg',
>>   '/Users/aclark/Developer/eggs/plone.recipe.zope2instance-3.6-py2.4.egg',
>>   '/Users/aclark/Developer/eggs/zc.recipe.egg-1.2.2-py2.4.egg',
>>   '/Users/aclark/Developer/eggs/distribute-0.6.14-py2.4.egg',
>>   
>> '/Users/aclark/Developer/python-buildout/python-2.4/lib/python2.4/site-packa
>> ges',
>>   '/Users/aclark/Developer/eggs/Products.PloneTestCase-0.9.9-py2.4.egg',
>> Š
>> 
>> 
>> If I list PIL in Buildout, I get the latest on PyPI (or some version I
>> specify) and it "breaks Zope" due to the issues we discussed.
>> 
>> As such, various alternative re-packages have appeared:
>> 
>> - http://download.zope.org/distribution/PILwoTk-1.1.6.4.tar.gz
>> - http://dist.repoze.org/PIL-1.1.6.tar.gz
>> - http://dist.plone.org/thirdparty/PIL-1.1.7.tar.gz
>> 
>> Now, you can use Buildout to install PILwoTk quite easily simply by telling
>> Buildout where to find it, e.g.:
>> 
>>   [buildout]
>>   find-links = http://download.zope.org/distribution/PILwoTk-1.1.6.4.tar.gz
>> 
>> But it's not clear (to me at least) if the same is true of the re-packages
>> that are not *renamed* e.g.
>> http://dist.plone.org/thirdparty/PIL-1.1.7.tar.gz
>> 
>> That is because Buildout's default index is PyPI and it will always find PIL
>> there first (I think).
>> 
>> So, I wanted a fork, because I wanted to take the latest re-packaging (
>> http://dist.plone.org/thirdparty/PIL-1.1.7.tar.gz) and "release" it to PyPI.
>> 
>> Now I can specify the Pillow package in Buildout, and Buildout will find
>> "the right one". (Here's a simple Plone buildout example:
>> http://svn.aclark.net/svn/public/buildout/plone/trunk/buildout.cfg)
>> 
>> Let me parse the rest of your and Fredrik's comments, and let them sink in a
>> bit, and get back to youŠ
>> 
>> (This is a very helpful dialogue I think, thank you all!)
>> 
>> 
>>> -Chris
>>> 
>>> 
>> 
> 

-- 
Alex Clark · http://aclark.net
Author — Plone 3.3 Site Administration · http://aclark.net/admin