* On 08.07.2014 01:28 pm, [email protected] wrote: > On 8 Jul 2014, at 02:00, Mihai Moldovan <[email protected]> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
