Re: [Numpy-discussion] NumPy 1.12.0b1 released
Congrats to all on the release.Two questions: Is there a guide to building standard wheels for NumPy? Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and OSX64, how can I get them blessed and uploaded to PyPI? Matti On 17/11/16 07:47, numpy-discussion-request@scipy.org wrote:
Hi, On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus <matti.picus@gmail.com> wrote:
Congrats to all on the release.Two questions:
Is there a guide to building standard wheels for NumPy?
I don't think so - there is a repository that we use to build the wheels, that has the Windows, OSX and manyllinux recipes for the standard CPython build: https://github.com/MacPython/numpy-wheelso If you can work out a way to automate the PyPy builds and tests - especially using the same repo - that would be very useful.
Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and OSX64, how can I get them blessed and uploaded to PyPI?
If you can automate the build and tests, I'm guessing there will be no objections - but it's not my call... Cheers, Matthew
On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
I'm in favor, assuming that the wheel tags and PyPy backwards compatibility situation is OK. Can't really find any examples. What I mean is that for CPython wheels contain tags like "cp27" or "cp35". PyPy wheels should have tags "pp<something>". Are the PyPy cpyext layer and the <something> defined such that a new PyPy release won't break older wheels? Ralf
On Nov 18, 2016 01:14, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett <matthew.brett@gmail.com>
wrote:
Another thing to think about is that 1.12 on pypy won't pass its test suite (though it's close), and we're not yet testing new PRs on pypy, so no guarantees about 1.13 yet. I think on balance these probably aren't reasons *not* to upload wheels, but it's a funny place where we're talking about providing "official" builds even though it's not an "officially supported platform". So we will at least want to be clear about that. And someone will have to handle the bug reports about the test suite failing :-). -n
I have a related question to Matti's, Do you have any recommendations for building standard wheels for 3rd party Python libraries which use both the NumPy Python and C API? e.g. Do we need to do anything special given the NumPy C API itself is versioned? Does it matter compiler chain should we use? Thanks Peter On Thu, Nov 17, 2016 at 11:24 PM, Matti Picus <matti.picus@gmail.com> wrote:
Since the NumPy API is forwards compatible, you should use the oldest version of NumPy you would like to support to build your wheels with. The wheels will then work with any future NumPy versions. On Fri, Nov 18, 2016 at 9:30 AM Peter Cock <p.j.a.cock@googlemail.com> wrote:
Thanks Nathan, That makes sense (compile using the oldest version of NumPy we wish to support). The information on https://github.com/MacPython/numpy-wheels will probably be very useful too (I've been meaning to try out appveyor at some point for Windows builds/testing). Regards, Peter On Fri, Nov 18, 2016 at 2:46 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi, On Thu, Nov 17, 2016 at 3:24 PM, Matti Picus <matti.picus@gmail.com> wrote:
Congrats to all on the release.Two questions:
Is there a guide to building standard wheels for NumPy?
I don't think so - there is a repository that we use to build the wheels, that has the Windows, OSX and manyllinux recipes for the standard CPython build: https://github.com/MacPython/numpy-wheelso If you can work out a way to automate the PyPy builds and tests - especially using the same repo - that would be very useful.
Assuming I can build standardized PyPy 2.7 wheels for Ubuntu, Win32 and OSX64, how can I get them blessed and uploaded to PyPI?
If you can automate the build and tests, I'm guessing there will be no objections - but it's not my call... Cheers, Matthew
On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
I'm in favor, assuming that the wheel tags and PyPy backwards compatibility situation is OK. Can't really find any examples. What I mean is that for CPython wheels contain tags like "cp27" or "cp35". PyPy wheels should have tags "pp<something>". Are the PyPy cpyext layer and the <something> defined such that a new PyPy release won't break older wheels? Ralf
On Nov 18, 2016 01:14, "Ralf Gommers" <ralf.gommers@gmail.com> wrote:
On Fri, Nov 18, 2016 at 9:08 PM, Matthew Brett <matthew.brett@gmail.com>
wrote:
Another thing to think about is that 1.12 on pypy won't pass its test suite (though it's close), and we're not yet testing new PRs on pypy, so no guarantees about 1.13 yet. I think on balance these probably aren't reasons *not* to upload wheels, but it's a funny place where we're talking about providing "official" builds even though it's not an "officially supported platform". So we will at least want to be clear about that. And someone will have to handle the bug reports about the test suite failing :-). -n
I have a related question to Matti's, Do you have any recommendations for building standard wheels for 3rd party Python libraries which use both the NumPy Python and C API? e.g. Do we need to do anything special given the NumPy C API itself is versioned? Does it matter compiler chain should we use? Thanks Peter On Thu, Nov 17, 2016 at 11:24 PM, Matti Picus <matti.picus@gmail.com> wrote:
Since the NumPy API is forwards compatible, you should use the oldest version of NumPy you would like to support to build your wheels with. The wheels will then work with any future NumPy versions. On Fri, Nov 18, 2016 at 9:30 AM Peter Cock <p.j.a.cock@googlemail.com> wrote:
Thanks Nathan, That makes sense (compile using the oldest version of NumPy we wish to support). The information on https://github.com/MacPython/numpy-wheels will probably be very useful too (I've been meaning to try out appveyor at some point for Windows builds/testing). Regards, Peter On Fri, Nov 18, 2016 at 2:46 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
participants (6)
-
Matthew Brett -
Matti Picus -
Nathan Goldbaum -
Nathaniel Smith -
Peter Cock -
Ralf Gommers