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
