Merge pull request #445 from icemac/new-pypi

Use the new PyPI at https://pypi.org/.

CHANGES.rst

@@ -4,7 +4,7 @@ Change History
 2.11.3 (unreleased)
 ===================
 
-- Nothing changed yet.
+- Update to use the new PyPI at https://pypi.org/.
 
 
 2.11.2 (2018-03-19)

doc/getting-started.rst

@@ -124,7 +124,7 @@ recipe
   will implement the part.  The value is a Python distribution
   requirement, as would be used with ``pip``.  In this case, we've
   specified `zc.recipe.egg
-  <https://pypi.python.org/pypi/zc.recipe.egg>`_ which is the name of
+  <https://pypi.org/project/zc.recipe.egg/>`_ which is the name of
   a Python project that provides a number of recipe implementations.
 
 eggs
@@ -186,9 +186,9 @@ Generating configuration and custom scripts
 
 The ``bobo`` program doesn't daemonize itself. Rather, it's meant to
 be used with a dedicated daemonizer like `zdaemon
-<https://pypi.python.org/pypi/zdaemon>`_ or `supervisord
+<https://pypi.org/project/zdaemon>`_ or `supervisord
 <http://supervisord.org/>`_.  We'll use a `recipe to set up zdaemon
-<https://pypi.python.org/pypi/zc.zdaemonrecipe>`_.  Our Buildout
+<https://pypi.org/project/zc.zdaemonrecipe>`_.  Our Buildout
 configuration becomes:
 
 .. code-block:: ini
@@ -325,7 +325,7 @@ The example shown above illustrates how Buildout is more than just a
 package installer such as ``pip``. Using Buildout recipes, we can
 install custom scripts and configuration files, and much more. For
 example, we could use `configure and make
-<https://pypi.python.org/pypi/zc.recipe.cmmi>`_ to install non-Python
+<https://pypi.org/project/zc.recipe.cmmi>`_ to install non-Python
 software from source, we could run JavaScript builders, or do anything
 else that can be automated with Python.
 
@@ -487,10 +487,10 @@ version requirements in their own file:
 
 Here, we've used the Buildout ``extends`` option to say that
 configurations should be read from ``versions.cfg`` (it's
-allowed to specify several files in ``extend``). Cconfigurations 
+allowed to specify several files in ``extend``). Cconfigurations
 should be read from the named file (or files) and the
 configuration in the current file should override configuration in the
-extended files. 
+extended files.
 To continue the example, our ``versions.cfg`` file
 might look like:
 
@@ -741,7 +741,7 @@ To get an interactive Python prompt, or you can run a script with it:
 If you need to work on multiple interdependent projects at the same
 time, you can name multiple directories in the ``develop`` option,
 typically pointing to multiple check outs.  A popular Buildout
-extension, `mr.developer <https://pypi.python.org/pypi/mr.developer>`_,
+extension, `mr.developer <https://pypi.org/project/mr.developer>`_,
 automates this process.
 
 Where to go from here?
@@ -777,11 +777,11 @@ details, as well as let you know about features not touched on here.
 .. [#finding-hundreds] You can list Buildout-related software,
    consisting mostly of Buildout recipes, using the
    `Framework :: Buildout
-   <https://pypi.python.org/pypi?:action=browse&show=all&c=512>`_
+   <https://pypi.org/search/?q=&o=&c=Framework+%3A%3A+Buildout>`_
    classifier search. These results miss recipes that don't provide
    classifier meta data.  Generally you can find a recipe for a task by
    searching the name of the task and the "recipe" in the `package
-   index <https://pypi.python.org/pypi>`_.
+   index <https://pypi.org/>`_.
 
 .. [#hypocritical] It's a little hypocritical to recommend installing
    Buildout into an otherwise clean environment, which is why Buildout

doc/reference.rst

@@ -129,7 +129,7 @@ Pass one or more section names as arguments to display annotation only for the g
 .. code-block:: console
 
    buildout annotate versions
-  
+
 
 .. _bootstrap-command:
 
@@ -200,8 +200,8 @@ doesn't have setuptools installed.  Normally today, setuptools *is*
 installed and you can just run setup scripts that use setuptools directly.
 
 Note that if you want to build and upload a package to the `standard
-package index <https://pypi.python.org/pypi>`_ you should consider
-using `zest.releaser <https://pypi.python.org/pypi/zest.releaser>`_,
+package index <https://pypi.org>`_ you should consider
+using `zest.releaser <https://pypi.org/project/zest.releaser>`_,
 which automates many aspects of software release including checking
 meta data, building releases and making version-control tags.
 
@@ -353,7 +353,7 @@ index
   <https://packaging.python.org/distributing/#name>`_ containing
   distributions for those projects.
 
-  If this isn't set, then ``https://pypi.python.org/simple/`` is used.
+  If this isn't set, then ``https://pypi.org/simple/`` is used.
 
 .. _install-from-cache-mode:
 

doc/topics/bootstrapping.rst

@@ -109,7 +109,7 @@ incompatible version of setuptools, because Buildout and setuptools
 were evolving rapidly, sometimes in lock step.
 
 This approach fails from time to time, due to changes in setuptools or
-`the package index <https://pypi.python.org/pypi>`_ and has been a
+`the package index <https://pypi.org/>`_ and has been a
 source of breakage when automated systems depended on it.
 
 It's also possible that this approach will stop being supported.

doc/topics/extensions.rst

@@ -16,4 +16,4 @@ and often experimental ways.  Use the ``extensions`` option in the
   ...
 
 Some other examples of extensions can be found in the `standard
-package index <https://pypi.python.org/pypi?:action=browse&c=512&c=546>`_.
+package index <https://pypi.org/search/?q=&o=&c=Framework+%3A%3A+Buildout+%3A%3A+Extension>`_.

doc/topics/writing-recipes.rst

@@ -496,7 +496,7 @@ More realistically:
 
 - You might use a test runner like nose or pytest.  There are `recipes
   that can help set this up
-  <https://pypi.python.org/pypi?%3Aaction=search&term=test+runner+buildout+recipe&>`_.
+  <https://pypi.org/search/?q=test+runner+buildout+recipe>`_.
   We just used the test runner built into ``unittest``.
 
 ``zc.buildout.testing`` reference

src/zc/buildout/allowhosts.txt

@@ -46,7 +46,7 @@ local files::
     ... develop = allowdemo
     ... parts = eggs
     ... allow-hosts =
-    ...     pypi.python.org
+    ...     pypi.org
     ...
     ... [eggs]
     ... recipe = zc.recipe.egg:eggs

src/zc/buildout/buildout.txt

@@ -3176,7 +3176,7 @@ using the `index` option::
   ...
   index = https://index.example.com/
 
-This index, or the default of https://pypi.python.org/simple/ if no
+This index, or the default of https://pypi.org/simple/ if no
 index is specified, will always be searched for distributions unless
 running buildout with options that prevent searching for
 distributions. The latest version of the distribution that meets the

src/zc/buildout/easy_install.py

@@ -56,7 +56,7 @@ def realpath(path):
 
 default_index_url = os.environ.get(
     'buildout-testing-index-url',
-    'https://pypi.python.org/simple',
+    'https://pypi.org/simple',
     )
 
 logger = logging.getLogger('zc.buildout.easy_install')

src/zc/buildout/easy_install.txt

@@ -46,7 +46,7 @@ index
    The URL of an index server, or almost any other valid URL. :)
 
    If not specified, the Python Package Index,
-   https://pypi.python.org/simple/, is used.  You can specify an
+   https://pypi.org/simple/, is used.  You can specify an
    alternate index with this option.  If you use the links option and
    if the links point to the needed distributions, then the index can
    be anything and will be largely ignored.  In the examples, here,
@@ -1112,7 +1112,7 @@ index
    The URL of an index server, or almost any other valid URL. :)
 
    If not specified, the Python Package Index,
-   https://pypi.python.org/simple/, is used.  You can specify an
+   https://pypi.org/simple/, is used.  You can specify an
    alternate index with this option.  If you use the links option and
    if the links point to the needed distributions, then the index can
    be anything and will be largely ignored.  In the examples, here,

src/zc/buildout/repeatable.txt

@@ -317,8 +317,8 @@ When everything is pinned, no output is generated:
     recipe v2
 
 The Python package index is case-insensitive. Both
-https://pypi.python.org/simple/Django/ and
-https://pypi.python.org/simple/dJaNgO/ work. And distributions aren't always
+https://pypi.org/simple/Django/ and
+https://pypi.org/simple/dJaNgO/ work. And distributions aren't always
 naming themselves consistently case-wise. So all version names are normalized
 and case differences won't impact the pinning: