PIL + ReportLab vs Pillow

Mihai Moldovan ionic at ionic.de
Tue Jul 8 06:31:56 PDT 2014


* On 08.07.2014 01:28 pm, petr at macports.org wrote:
> On 8 Jul 2014, at 02:00, Mihai Moldovan <ionic at ionic.de> wrote:
>
>> * On 07.07.2014 11:32 am, Peter Danecek wrote:
>>> Why not allowing that either PIL or Pillow satisfies the dependency where possible.
>>> [...]
>>> This would avoid potential conflicts if users need to install other (still) PIL dependent software.
>> That would be possible, yes. But as I understood it, Pillow is a drop-in
>> replacement for PIL and is always supposed to work with software initially
>> written for PIL.
> Probably, yes. But I do not know the details about compatibility, so would not make the statement that Pillow can *always* replace PIL.
I found this:

> +1. The only thing Pillow could not provide was the distribution name
> "PIL" on PyPI. So you must "pip install Pillow" instead of PIL.
> Everything else e.g. "from PIL import Image" should be the same.

> Alex Clark, Pillow (PIL fork) author

From that, and the fact that most Linux distributions are only shipping Pillow
(checked Debian, Gentoo, Centos -- all with the same result) and not seem to be
running into trouble or even patching packages that formerly used PIL, I think
it's safe to say that Pillow can *always* replace PIL.
(Just not the other way around.)


>> However, I'm not a python programmer and might be wrong.
>>
>> My thinking was that, as Pillow is supposed to be a PIL-compatible drop-in
>> replacement, we could avoid all problems like
>> - package1 -> Pillow
>> - package2 -> PIL
>> => package1 can't be installed at the same time with package2 (and vice versa)
> This is why I am proposing the solution above. If at least one of the above packages (e.g. package1) can install with both alternatives, you will be able to install, but the sequence is relevant. If both support alternative, you have no problem at all.
>
> Of cause, if you would replace PIL as dependency in all ports at one time, no conflicts arise.

I'll replace all occurrences of PIL with the path:-based alternative you suggested.

>> (Note that while PIL is supposed to always be substitutable with Pillow, the
>> other way is not possible, if specialized Pillow features are being used.)
>>
>> Does that make sense?
> I this is true, PIL could be phased out at some point.

Yes, this is what I'm aiming at. It hasn't been updated in 4 years anyway, while
Pillow is still actively developed. (We can leave PIL in the tree, I'd just like
to get all dependencies switched to Pillow. Maybe PIL development will magically
pick up again one day, who knows.)



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4265 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20140708/6c4f4b78/attachment.p7s>


More information about the macports-users mailing list