@@ -387,6 +387,58 @@ Trigger a build by doing an empty (or otherwise) commit to the repository::
387
387
388
388
The wheels, once built, appear in http://wheels.scipy.org
389
389
390
+ Trigger Windows builds on Appveyor
391
+ ----------------------------------
392
+
393
+ See: `build Windows wheels `_
394
+
395
+ * Clone / update the https://github.com/numpy/windows-wheel-builder repository;
396
+ * Check the ``appveyor.yml `` file in that repository;
397
+ * Edit the line starting ``NP_VERSION: `` to give the numpy tag that you want
398
+ to build;
399
+ * Push up to github to trigger a build.
400
+
401
+ The wheels appear in a Rackspace CDN container at:
402
+
403
+ * http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com
404
+ * https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com
405
+
406
+ The contents via the HTTPS URL seems to get updated more slowly than via the
407
+ HTTP URL, so if you need the binaries quickly, prefer the HTTP URL.
408
+
409
+ .. _build Windows wheels : https://github.com/numpy/windows-wheel-builder
410
+
411
+ Trigger Manylinux builds on travis-ci
412
+ -------------------------------------
413
+
414
+ .. note ::
415
+
416
+ Until we move the manylinux build scripts, you'll need to ask
417
+ ``@matthew-brett `` to make you a collaborator on the manylinux repos.
418
+
419
+ * Clone / update the repository at
420
+ https://github.com/matthew-brett/manylinux-builds
421
+ * Edit the line in ``.travis.yml `` starting ``NUMPY_VERSIONS= `` to set the
422
+ numpy tag to build;
423
+ * Push your edits to ``.travis.yml `` up to github to trigger a mass manylinux
424
+ build;
425
+ * Clone / update the repository at
426
+ https://github.com/matthew-brett/manylinux-testing;
427
+ * Push an empty commit to the ``manylinux-testing `` repo to trigger a test run
428
+ of the newly-built numpy wheels with a range of dependent libraries, as well
429
+ as numpy's own unit tests. The tests will take several hours.
430
+
431
+ The built wheels will be available from a Rackspace CDN container at:
432
+
433
+ * http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
434
+ * https://d9a97980b71d47cde94d-aae005c4999d7244ac63632f8b80e089.ssl.cf2.rackcdn.com
435
+
436
+ As for the other Rackspace containers, the HTTP address may update first, and
437
+ you should wait 15 minutes after the build finishes before fetching the
438
+ binaries. For the manylinux wheels, the time to run ``manylinux-testing `` is
439
+ much greater than 15 minutes, so waiting for the tests to pass will be enough
440
+ time for the binaries to refresh on Rackspace.
441
+
390
442
Make the release
391
443
----------------
392
444
@@ -403,11 +455,48 @@ For example::
403
455
404
456
scp <filename> <username>,numpy@frs.sourceforge.net:/home/frs/project/n/nu/numpy/NumPy/<releasedir>/
405
457
406
- Update PyPi
458
+ Update PyPI
407
459
-----------
408
460
409
- The final release (not betas or release candidates) should be uploaded to PyPi.
410
- There are two ways to update PyPi, the first one is::
461
+ The wheels and source should be uploaded to PyPI.
462
+
463
+ You should upload the wheels first, and the source formats last, to make sure
464
+ that pip users don't accidentally get a source install when they were
465
+ expecting a binary wheel.
466
+
467
+ You can do this automatically using the ``wheel-uploader `` script from
468
+ https://github.com/MacPython/terryfy. Here is the recommended incantation for
469
+ downloading all the Windows, Manylinux, OSX wheels and uploading to PyPI.
470
+
471
+ ::
472
+
473
+ cd ~/wheelhouse # local directory to cache wheel downloads
474
+ MANYLINUX_URL=http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com
475
+ WINDOWS_URL=http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com
476
+ OSX_URL=http://wheels.scipy.org
477
+ wheel-uploader -u $MANYLINUX_URL -v -s -t manylinux1 numpy 1.11.1rc1
478
+ wheel-uploader -u $WINDOWS_URL -v -s -t win numpy 1.11.1rc1
479
+ wheel-uploader -u $OSX_URL -v -s -t macosx numpy 1.11.1rc1
480
+
481
+ The ``-v `` flag gives verbose feedback, ``-s `` causes the script to sign the
482
+ wheels with your GPG key before upload.
483
+
484
+ You may well find that these uploads break at some point, with error messages
485
+ from the PyPI server. In this case you'll have to continue the uploads by
486
+ hand using `twine <https://pypi.python.org/pypi/twine >`_, using something
487
+ like::
488
+
489
+ twine upload -s numpy-1.11.1rc1-cp34-*.whl
490
+
491
+ Do this for the wheel files that ``wheel-uploader `` downloaded, but for which
492
+ the upload failed.
493
+
494
+ The ``warehouse `` PyPI server seems to be more reliable in receiving automated
495
+ wheel uploads. You can set the repository to upload to with the ``-r `` flag
496
+ to ``wheel-uploader `` and ``twine ``. The warehouse repository URL for your
497
+ ``~/.pypirc `` file is https://upload.pypi.io/legacy/
498
+
499
+ There are two ways to update the source release on PyPI, the first one is::
411
500
412
501
$ git clean -fxd # to be safe
413
502
$ python setup.py sdist --formats=gztar,zip # to check
@@ -417,10 +506,10 @@ This will ask for your key PGP passphrase, in order to sign the built source
417
506
packages.
418
507
419
508
The second way is to upload the PKG_INFO file inside the sdist dir in the
420
- web interface of PyPi . The source tarball can also be uploaded through this
509
+ web interface of PyPI . The source tarball can also be uploaded through this
421
510
interface.
422
511
423
- To push the travis-ci OSX wheels up to pypi see :
512
+ To push the travis-ci OSX wheels up to PyPI see :
424
513
https://github.com/MacPython/numpy-wheels#uploading-the-built-wheels-to-pypi
425
514
426
515
.. _push-tag-and-commit :
0 commit comments