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
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* ;-)
Alex Clark · http://aclark.net
Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Repoze-dev mailing list