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?


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

Reply via email to