Add pyproject.toml

[jorisvandenbossche]

Now that pip 19 is out, we can attempt to re-add pyproject.toml

---

The release of pip version 10 and the presence of a pyproject.toml in our latest released versions gives problems for installing pandas in the following cases:

Problem with installing pandas for Python 3.4

• You get the error "Double requirement given: numpy ..."
• The reason for this error is that pandas 0.21-0.22 no longer supports Python 3.4, and thus no longer distributes binary wheels for Python 3.4. Therefore, pip tries to install pandas from source, and this is what now started to fail with Pip version 10.
• Solution:

  • Install an older version of pandas

    pip install pandas<0.21
    

  • Workaround for package maintainers to specify the pandas version in install_requires: pip install panadas fails on numpy version #20697 (comment)

• The fact that those version are downloaded for Python 3.4 (instead of an older compatible version) was a bug in our setup.py, and this will be fixed in future versions of pandas: DEP: Add 'python_requires' to setup.py to drop 3.4 support #20698

Problem with installing pandas on "special" platforms (32bit, PyPy, ARM, ...) (building from source):

• You get the error "No matching distribution found for Cython"
• The reason for this error is that we do not provide wheels for such python versions or platforms. In such a case, pip will try to build pandas from source, but this started to fail with pip version 10. This is because their limited support for PEP518, and they require that all build dependencies of pandas are installed from wheels (Build dependencies with no binary wheels don't work pypa/pip#5229), which are often also not available on those python versions / platforms.
• Solution
  • Use an older version of pip
  • Use pip install pandas --no-build-isolation
• See eg Installation of Pandas in Pip v10.0.0b2 on PyPy fails #20666, Pandas installation on arm architectures #20771

[TomAugspurger]

Do we know if there's any way to fix the 0.21.x and 0.22.x releases for python 3.4, or does this fall entirely on users? e.g. if we were to upload a 0.21.2 and 0.22.1 with just the python_requires fix, I assume pip install pandas would still pull down 0.22.0, right?

[jorisvandenbossche]

Yes, I don't think we can fix it, because even if we would do a 0.22.1 with the correction, I suppose as well that pip will find the existing 0.22.0 as the next in line that it can install.

[jreback]

the way to fix this is to re-issue the existing wheels (with this one change) on 0.21 and 0.22. but that is 'banned' by PyPi. Its equivalent in conda of bumping the version number, but AFAIK no way to do this on PyPi.

so maybe ask on the pip tracker on what is possible?

maybe could just put an extra waring in the docs.

[TomAugspurger]

Its equivalent in conda of bumping the version number

I assume you meant the build number? The wheels aren't the problem, since those are version-specific. A python 3.4 user installing pandas will get the source dist for 0.22.0. But we can't change the source. At this point, I think we just document that python 3.4 users should pin their version of pandas explicitly.

…

On Sat, Apr 21, 2018 at 12:33 PM, Jeff Reback ***@***.***> wrote: the way to fix this is to re-issue the existing wheels (with this one change) on 0.21 and 0.22. but that is 'banned' by PyPi. Its equivalent in conda of bumping the version number, but AFAIK no way to do this on PyPi. so maybe ask on the pip tracker on what is possible? maybe could just put an extra waring in the docs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20775 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHInOVQfItIvv4b6Oi-WtBQwThO7-pks5tq22EgaJpZM4TeY5p> .

[jorisvandenbossche]

so maybe ask on the pip tracker on what is possible?

Well, I already commented on some of the issues, and I suggested an option is for them to disable the new (partial) PEP518 support by default, but I don't have the impression that they will do that.

I don't think there is anything to do for 0.23 (I mainly opened this issue as a point-to issue with a summary of the situation, to point to in case other duplicate issues are opened).
I think the only thing we can do for 0.23.0 is to update documentation on how to use pip install pandas in case of 'special' platforms.

[maximveksler]

adding 2 cents:

I'm building pandas from source on Windows as part our development process, it started failing on dev machines and the work around was to add the --no-build-isolation.

From a pandas user perspective "something that worked before break now, without me changing anything".

So I don't think it's just an issue with the "special" platforms, it also applies to users of windows that are building the library from source.

[TomAugspurger]

Edited the original post to indicate that the "special platforms" thing is just the most common case of users having to build from source.

…

On Sun, Apr 29, 2018 at 12:28 AM, Maxim Veksler ***@***.***> wrote: adding 2 cents: I'm building pandas from source on Windows as part our development process, it started failing on dev machines and the work around was to add the --no-build-isolation. From a pandas user perspective "something that worked before break now, without me changing anything". So I don't think it's just an issue with the "special" platforms, it also applies to users of windows that are building the library from source. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#20775 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHIhYbmxKHpBqZ1llPitpIVghLEmVxks5ttU93gaJpZM4TeY5p> .

[jorisvandenbossche]

Yes, the reason I put "special platforms" is because there you automatically build from source with pip, while for "common" platforms the default is just installing from wheels.

From a pandas user perspective "something that worked before break now, without me changing anything".

You are completely right, but unfortunately, there is nothing we can do about it. We partly caused it by prematurely adding a pyproject.toml, but now it is only pip who can fix it.