No ci skip here because let's see CI run w/new version numbers. I'm starting to think (again) this bump should happen immediately after the release instead of right before the next? But I know @wiredfool had some objection to this at some point. As a compromise, maybe we could change to 2.9.0dev immediately following the release of 2.8.0.
It made the PyPI listing page very long and requires a lot of scrolling to get down to the files, annoying for downstream packagers.
Instead it's linked from the README.
[CI skip]
When installing Pillow onto a Vagrant virtual machine with Linux as the guest OS, and Windows as the host OS, setup.py fails with the error "Text file busy." The temporary installation directory is a shared folder from the host OS, mounted in the guest OS, and the underlying Windows file system doesn't allow deleting the "multiarch" temporary file while a file handle for it is still open. This change closes the file handle once it is no longer being used, but before the file itself is unlinked.
Though I hate the 'dev' designation I want something to indicate master is where development for the next major version happens. I think we've previously disagreed on simply 'X.X.X' so I'm going with 'X.X.Xdev' to see if that is more palatable. :-)
The subprocess command in Python 3 returns a bytes object. If the
homebrew subprocess check returns a not-empty result, then setup crashes
trying to combine the bytes with the string constants with and error
like "TypeError: Can't mix strings and bytes in path components."
XQuartz ships an older freetype that still has a top-level "ft2build.h"
header file. Homebrew's freetype is newer and does not have this file,
it only has "freetype2/ft2build.h".
setup.py finds the header in XQuartz first, but Homebrew's compiler
wrappers intentionally strip out the XQuartz include paths during the
build unless the package depends on it explicitly.
We want to prefer Homebrew's freetype anyway, so if it's installed,
let's not even bother to search the XQuartz paths.
platforma.processor() will return x86_64 on a 64 bit linux system;
however, this it wrong for 32 bit compiled python. By looking at
platform.architecture() first it correctly notes the 32bit
compile.
