[gentoo-python] Thoughts on PIL and Pillow

[gentoo-python] Thoughts on PIL and Pillow

[Mike Gilbert]

Hi all,

I would like to collect opinions on how to handle PIL
(dev-python/imaging) and its fork Pillow.

PIL allows its modules to be imported from the PIL namespace, or from
the top-level namespace for backward compatibility. For example:

import Image # legacy import
from PIL import Image

Pillow removes the backward compatibility and no longer allows imports
from the top-level namespace.

Arfrever and I have assembled a tracker bug of packages which need
updating to be compatible with Pillow.

https://bugs.gentoo.org/show_bug.cgi?id=471488

The question I have: Is it better to have Pillow as a separate package
and set up a virtual, or should Pillow just be added as a version bump
of dev-python/imaging?

The portage tree currently has both dev-python/imaging-2.0.0
(hard-masked), and dev-python/pillow-2.0.0. My intent was to eliminate
dev-python/pillow with a pkg move, but upon further consideration I
would like to gather some more opinions on the matter.

Re: [gentoo-python] Thoughts on PIL and Pillow

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Tue, 28 May 2013 13:45:22 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> The question I have: Is it better to have Pillow as a separate package
> and set up a virtual, or should Pillow just be added as a version bump
> of dev-python/imaging?
> 
> The portage tree currently has both dev-python/imaging-2.0.0
> (hard-masked), and dev-python/pillow-2.0.0. My intent was to eliminate
> dev-python/pillow with a pkg move, but upon further consideration I
> would like to gather some more opinions on the matter.

Moving forks onto original packages sounds much like Arfrever was doing
in the past. That's why we have dev-python/setuptools which is not
setuptools, doesn't it?

Merging two unmerged projects into a single ebuild is a mess. Just keep
them separate, make a virtual for it. When packages work with pillow,
switch them to the virtual.

And if we decide to drop dev-python/imaging in the future, we'll just
change virtual deps to pillow.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-python] Thoughts on PIL and Pillow

[yac]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Tue, 28 May 2013 19:58:40 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Tue, 28 May 2013 13:45:22 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
> 
> > The question I have: Is it better to have Pillow as a separate
> > package and set up a virtual, or should Pillow just be added as a
> > version bump of dev-python/imaging?
> > 
> > The portage tree currently has both dev-python/imaging-2.0.0
> > (hard-masked), and dev-python/pillow-2.0.0. My intent was to
> > eliminate dev-python/pillow with a pkg move, but upon further
> > consideration I would like to gather some more opinions on the
> > matter.
> 
> Moving forks onto original packages sounds much like Arfrever was
> doing in the past. That's why we have dev-python/setuptools which is
> not setuptools, doesn't it?
> 
> Merging two unmerged projects into a single ebuild is a mess. Just
> keep them separate, make a virtual for it. When packages work with
> pillow, switch them to the virtual.

+1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-python] Thoughts on PIL and Pillow

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 460 bytes --]

2013-05-28 19:58 Michał Górny napisał(a):
> Moving forks onto original packages sounds much like Arfrever was doing
> in the past. That's why we have dev-python/setuptools which is not
> setuptools, doesn't it?

It was not any mistake, but a well planned change. See:
http://mail.python.org/pipermail/distutils-sig/2013-March/020126.html
http://mail.python.org/pipermail/distutils-sig/2013-May/020838.html

--
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]