Replace PIL with Pillow on PyPI

[matysek]

Is there any chance that Pillow team could take over ownership of PyPI page https://pypi.python.org/pypi/PIL/ and that Pillow would became the "official" version of PIL?

It would be nice if Pillow could be installed just by command pip install PIL.

[wiredfool]

I think we'd need Fredrik Lundh to do that, and I haven't seen anything him in ~5 years.

That entry is ancient, as it even predates the last actual PIL release, which was 1.1.7.

[radarhere]

If this is the way to go, it looks like one would create a support request to recover the page from Fredrik Lundh, along the lines of http://sourceforge.net/p/pypi/support-requests/562/

[hugovk]

Or contact the author directly. That's what I did with my fork of pylast, and he gave me access: pylast/pylast#92.

[radarhere]

In trying to find contact details, a WHOIS lookup for effbot.org will provide an e-mail address. There is an @effbot user on GitHub, but that may or may not be Fredrik Lundh.

I presume that we'd want @aclark4life to become the owner of the index page.

[hugovk]

Try this: https://github.com/google/closure-templates/blob/master/python/abstract_translator.py#L35

[radarhere]

Thanks. I've sent an e-mail, we'll see what happens.

[aclark4life]

I don't expect to hear from Fredrik, but of course it can't hurt to ask. For reference, here's where Pillow was introduced in July 2010:

• https://mail.python.org/pipermail/image-sig/2010-July/006423.html

More interesting comments in August 2010:

• https://mail.python.org/pipermail/image-sig/2010-August/thread.html

My favorite comment from Fredrik, which gave my effort legitimacy (in my mind), is here:

• https://mail.python.org/pipermail/image-sig/2010-August/006429.html

At least a packaging fork means that someone's over there is producing something more than
invectives, but I'd still prefer a patch.

Regarding whether we want this to happen, maybe. There's a lot to think about with regard to Pillow actually becoming PIL and I've not done any of that thinking yet. I'm not opposed to it, but I'd want to make sure it was "done right" and I'm not sure what that means. At the very least, I'd want to have a good reason and I'd want to reduce confusion, not add to it.

[radarhere]

Fredrik replied, saying that he'd attempt to get around to it next week.

I'm not necessarily advocating that we do make Pillow the 'official' version of PIL. I do think that updating the page to show 1.1.7 would be good, and changing the description to make people aware of Pillow would be good.

[aclark4life]

@radarhere Great, glad to hear

[wiredfool]

+1 @aclark4life

[aclark4life]

I'm going to assume this isn't going to happen. Please reopen if I'm wrong or if something changes. (And I'm still not sure I'd want it to happen, though I guess we could make it work somehow; possibly by releasing Pillow as both Pillow & PIL for a while.)

[verhovsky]

I started a PEP 541 issue about this on the pypa repo

https://github.com/pypa/warehouse/issues/6660

[aclark4life]

@verhovsky Never say never, I guess… thanks for trying! Also need @python-pillow/pillow-team to think about how to support it, if it happens.

[jamadden]

Hi @aclark4life and @python-pillow, the PyPI moderators have exhausted the PEP 541 process for contacting the PIL project owner. At this point, we can consider PIL officially abandoned. Are you interested in acquiring the name or would that just be too much of a complication?

[aclark4life]

@jamadden We'll take it, thanks. I imagine we'll release identical distributions of PIL and Pillow for the foreseeable future… RIP PIL, long live PIL/Pillow!

[jamadden]

@aclark4life I'll ask the admins to initiate the transfer; I'll just ask to add one owner (aclark) and let you add additional owners/maintainers as appropriate. I assume you'll leave the existing PIL releases in place?

[hugovk]

I imagine we'll release identical distributions of PIL and Pillow for the foreseeable future…

Let's think carefully what exactly we'll put under PIL. If we put the same Pillow distribution under both, there could be confusion about what exactly is installed.

A simple wrapper from PIL to install Pillow is another option, but could also cause installation/upgrade confusion.

I think a warning/error from pip install pil would be simplest, saying to pip install pillow instead.

For comparison, see scikit-learn/scikit-learn#8215.

[aclark4life]

@jamadden Yes we'll leave the existing releases intact, and sounds good to me @hugovk, good plan.

[ewdurbin]

Transfer as requested (to PyPI user aclark) is complete.

[aclark4life]

@ewdurbin Looks like I forgot to save my recovery codes, can you please remove my 2FA and I'll re-setup and save codes this time? Thanks

[aclark4life]

@matysek Getting there!!

I'd like to leave this issue open for a little while longer (not another five years) until we figure out what to do, if that's OK with you.

[radarhere]

As an aside, since we now have control over PyPI PIL, is it worth publishing PIL 1.1.7 there?

[wiredfool]

No, there’s no way we should post anything with that many CVEs.

[aclark4life]

I just noticed that effbot.org has gone dark recently.

As such, pip install pil (which likely previously failed, particularly in Python 3) now don't happen because PIL's distributions were externally hosted.

I'm not saying any of this really matters, just that the needle may have moved slightly further towards me wanting to make pip install pil result in a Pillow installation.

Can we do that @python-pillow/pillow-team ? Off the top of my head, I know we could automate replacement of name = 'pillow' in setup.py with name = 'pil'.

[jamadden]

My understanding is that, since pip 10 from 2018 it is no longer possible to access external distributions at all, so it doesn't matter that the host isn't up. (This dates back to 2014 and PEP 470.)

A fairly common pattern in situations like this, where one distribution wishes to replace another distribution, but still allow installing using the original name, is to simply have a near-empty distribution under the original name that does nothing but list a dependency on the new project. So pip install pil would result in installing no files itself, but automatically install its dependency, pillow. One example I know of off the top of my head is ZODB3. That was split into ZODB, BTrees, etc, but pip install ZODB3 still works because the ZODB3 distribution does nothing but list those dependencies.

(EDIT: That may have been what hugovk was talking about.)

[aclark4life]

@jamadden @hugovk Yaaaas! Why didn't I think of that 😄 Yeah, that's what we should do.

[aclark4life]

@python-pillow/pillow-team In the case of a PIL distribution with install_requires=['Pillow',] seems like with every Pillow release we should publish a new PIL release with matching Pillow version so that folks running pip install pil will get the corresponding Pillow e.g. PIL setup.py

setup(
  …
  version = '8.1.0',
  install_requires = ['Pillow==8.1.0',]
  …
)

?

We'd also need some volunteers to test "in the wild" if and when such a PIL release were made.

[hugovk]

My understanding is that, since pip 10 from 2018 it is no longer possible to access external distributions at all, so it doesn't matter that the host isn't up. (This dates back to 2014 and PEP 470.)

Thanks, good to know, I think it actually helps us as pip install pil fails and should help avoid conflicts/confusion with Pillow.

(EDIT: That may have been what hugovk was talking about.)

Yep, something like that, and also a setup.py something like the one @aclark4life showed, and perhaps it could be automated but it'd be much better to avoid syncing versions and having to release each time.

Because there are pil releases on PyPI, we couldn't/shouldn't use 0.0.0, maybe PIL version 1.1.8 (the last PIL release was 1.1.7) and keep the Pillow dependency unpinned, to allow pip to be able to find and install last good releases for Python 2.7, 3.5 and so on.

setup(
  …
  version = '1.1.8',
  install_requires = ['Pillow',]
  …
)

It'd fix pip install pil failing, people will get Pillow instead of an error. Searching, people do pip install pil from time to time. It would be nice to do this, although the correction is easy enough, install pillow not pil.

However, I'm still on the fence as I'd like to avoid additional installation difficulties, which are already a fairly large and frequent chunk of reported issues, often stuff like this, and I could imagine throwing two packages into the mix could stir things further.

[radarhere]

Shall we at least update the https://pypi.org/project/PIL/ description to mention Pillow?

[jamadden]

The only way to update the description is to upload a new version.

[radarhere]

Ok then! Thanks for the info.

[aclark4life]

@python-pillow/pillow-team FYI, invites sent to PIL

[hugovk]

Thanks, accepted!

---

Back to the OP question:

Is there any chance that Pillow team could take over ownership of PyPI page pypi.python.org/pypi/PIL and that Pillow would became the "official" version of PIL?

It would be nice if Pillow could be installed just by command pip install PIL.

Once upon a time, the releases on PyPI had their installation files hosted elsewhere than PyPI.

Later, PyPI also offered hosting itself (see also PEP 438).

Then in 2015, PEP 470 removed support for externally-hosted files (pypi/warehouse#431), meaning all files must be hosted on PyPI.

It used to be that you could pip install pil and pip install pillow and not really be sure which you had. Hence the warning at https://pillow.readthedocs.io/en/latest/deprecations.html#pillow-and-pil:

Pillow and PIL cannot co-exist in the same environment. Before installing Pillow, please uninstall PIL.

However, all the releases at https://pypi.python.org/pypi/PIL/ are from 2006 and earlier, and were all externally-hosted files. That means pip install pil no longer works:

❯ pip install pil
ERROR: Could not find a version that satisfies the requirement pil (from versions: none)
ERROR: No matching distribution found for pil

This means no more confusion over having PIL and Pillow both installed at the same time.

I recommend we leave PIL on PyPI as it is: don't release any kind of shim so that pip install pil would install Pillow. Let attempted installs of PIL give an error.

This should help keep the installation story simpler: install pillow.

(It's already complicated enough with people installing pillow for one Python interpreter, but running a Python script for another (for example).)