From 6fb157d902b67a0c5d859ae66131c43418547e00 Mon Sep 17 00:00:00 2001 From: Henry Schreiner Date: Thu, 29 Oct 2026 11:40:05 -0400 Subject: [PATCH] chore: remove obsolete orphan pages, use redirects for moved ones Remove four obsolete orphan guides and the AppVeyor sample. Replace the three stub pages with sphinx-reredirects redirects. Assisted-by: ClaudeCode:claude-opus-5-5 --- requirements.txt | 1 + source/conf.py | 21 ++ source/guides/appveyor-sample/appveyor.yml | 52 ---- source/guides/appveyor-sample/build.cmd | 21 -- source/guides/migrating-to-pypi-org.rst | 142 ----------- source/guides/multi-version-installs.rst | 39 --- .../single-sourcing-package-version.rst | 8 - .../supporting-multiple-python-versions.rst | 135 ---------- .../supporting-windows-using-appveyor.rst | 235 ------------------ source/guides/using-manifest-in.rst | 9 - source/tutorials/creating-documentation.rst | 7 - 11 files changed, 22 insertions(+), 648 deletions(-) delete mode 100644 source/guides/appveyor-sample/appveyor.yml delete mode 100644 source/guides/appveyor-sample/build.cmd delete mode 100644 source/guides/migrating-to-pypi-org.rst delete mode 100644 source/guides/multi-version-installs.rst delete mode 100644 source/guides/single-sourcing-package-version.rst delete mode 100644 source/guides/supporting-multiple-python-versions.rst delete mode 100644 source/guides/supporting-windows-using-appveyor.rst delete mode 100644 source/guides/using-manifest-in.rst delete mode 100644 source/tutorials/creating-documentation.rst diff --git a/requirements.txt b/requirements.txt index 02f5e9919d..2af52ed4e9 100644 --- a/requirements.txt +++ b/requirements.txt @@ -6,3 +6,4 @@ sphinx-copybutton==0.5.2 sphinx-toolbox==4.3.1 sphinx-jsonschema==1.20.1 sphinx-notfound-page==1.1.0 +sphinx-reredirects==1.1.0 diff --git a/source/conf.py b/source/conf.py index 8a50d77980..68ec32a28a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -39,6 +39,7 @@ "sphinx_toolbox.collapse", "sphinx-jsonschema", "notfound.extension", + "sphinx_reredirects", ] nitpicky = True @@ -272,5 +273,25 @@ def fix_notfound_links(app, doctree, docname): replace_uris(app, doctree, nodes.reference, "refuri") +# -- Options for sphinx-reredirects ---------------------------------------------------- +# https://documatt.com/sphinx-reredirects/usage/ + +redirects = { + "guides/using-manifest-in": "https://setuptools.pypa.io/en/latest/userguide/miscellaneous.html", + "tutorials/creating-documentation": "https://www.sphinx-doc.org/en/master/tutorial/", +} + +# Internal redirects, made relative for the current builder (html or dirhtml) +internal_redirects = { + "guides/single-sourcing-package-version": "discussions/single-source-version", +} + + +def add_internal_redirects(app): + for source, target in internal_redirects.items(): + app.config.redirects[source] = app.builder.get_relative_uri(source, target) + + def setup(app): + app.connect("builder-inited", add_internal_redirects) app.connect("doctree-resolved", fix_notfound_links) diff --git a/source/guides/appveyor-sample/appveyor.yml b/source/guides/appveyor-sample/appveyor.yml deleted file mode 100644 index 97dedea1aa..0000000000 --- a/source/guides/appveyor-sample/appveyor.yml +++ /dev/null @@ -1,52 +0,0 @@ -environment: - - matrix: - - # For Python versions available on Appveyor, see - # https://www.appveyor.com/docs/windows-images-software/#python - # The list here is complete (excluding Python 2.6, which - # isn't covered by this document) at the time of writing. - - - PYTHON: "C:\\Python27" - - PYTHON: "C:\\Python33" - - PYTHON: "C:\\Python34" - - PYTHON: "C:\\Python35" - - PYTHON: "C:\\Python27-x64" - - PYTHON: "C:\\Python33-x64" - DISTUTILS_USE_SDK: "1" - - PYTHON: "C:\\Python34-x64" - DISTUTILS_USE_SDK: "1" - - PYTHON: "C:\\Python35-x64" - - PYTHON: "C:\\Python36-x64" - -install: - # We need wheel installed to build wheels - - "%PYTHON%\\python.exe -m pip install wheel" - -build: off - -test_script: - # Put your test command here. - # If you don't need to build C extensions on 64-bit Python 3.3 or 3.4, - # you can remove "build.cmd" from the front of the command, as it's - # only needed to support those cases. - # Note that you must use the environment variable %PYTHON% to refer to - # the interpreter you're using - Appveyor does not do anything special - # to put the Python version you want to use on PATH. - - "build.cmd %PYTHON%\\python.exe setup.py test" - -after_test: - # This step builds your wheels. - # Again, you only need build.cmd if you're building C extensions for - # 64-bit Python 3.3/3.4. And you need to use %PYTHON% to get the correct - # interpreter - - "build.cmd %PYTHON%\\python.exe setup.py bdist_wheel" - -artifacts: - # bdist_wheel puts your built wheel in the dist directory - - path: dist\* - -#on_success: -# You can use this step to upload your artifacts to a public website. -# See Appveyor's documentation for more details. Or you can simply -# access your wheels from the Appveyor "artifacts" tab for your build. diff --git a/source/guides/appveyor-sample/build.cmd b/source/guides/appveyor-sample/build.cmd deleted file mode 100644 index 23df2b69b8..0000000000 --- a/source/guides/appveyor-sample/build.cmd +++ /dev/null @@ -1,21 +0,0 @@ -@echo off -:: To build extensions for 64 bit Python 3, we need to configure environment -:: variables to use the MSVC 2010 C++ compilers from GRMSDKX_EN_DVD.iso of: -:: MS Windows SDK for Windows 7 and .NET Framework 4 -:: -:: More details at: -:: https://github.com/cython/cython/wiki/CythonExtensionsOnWindows - -IF "%DISTUTILS_USE_SDK%"=="1" ( - ECHO Configuring environment to build with MSVC on a 64bit architecture - ECHO Using Windows SDK 7.1 - "C:\Program Files\Microsoft SDKs\Windows\v7.1\Setup\WindowsSdkVer.exe" -q -version:v7.1 - CALL "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64 /release - SET MSSdk=1 - REM Need the following to allow tox to see the SDK compiler - SET TOX_TESTENV_PASSENV=DISTUTILS_USE_SDK MSSdk INCLUDE LIB -) ELSE ( - ECHO Using default MSVC build environment -) - -CALL %* diff --git a/source/guides/migrating-to-pypi-org.rst b/source/guides/migrating-to-pypi-org.rst deleted file mode 100644 index 2b565e8eef..0000000000 --- a/source/guides/migrating-to-pypi-org.rst +++ /dev/null @@ -1,142 +0,0 @@ -:orphan: - -.. _`Migrating to PyPI.org`: - -Migrating to PyPI.org -===================== - -:Page Status: Obsolete - -:term:`pypi.org` is the new, rewritten version of PyPI that has replaced the -legacy PyPI code base. It is the default version of PyPI that people are -expected to use. These are the tools and processes that people will need to -interact with ``PyPI.org``. - -Publishing releases -------------------- - -``pypi.org`` is the default upload platform as of September 2016. - -Uploads through ``pypi.python.org`` were *switched off* on **July 3, 2017**. -As of April 13th, 2018, ``pypi.org`` is the URL for PyPI. - -The recommended way to migrate to PyPI.org for uploading is to ensure that you -are using a new enough version of your upload tool. - -The default upload settings switched to ``pypi.org`` in the following versions: - -* ``twine`` 1.8.0 -* ``setuptools`` 27.0.0 -* Python 2.7.13 (``distutils`` update) -* Python 3.4.6 (``distutils`` update) -* Python 3.5.3 (``distutils`` update) -* Python 3.6.0 (``distutils`` update) - -In addition to ensuring you're on a new enough version of the tool for the -tool's default to have switched, you must also make sure that you have not -configured the tool to override its default upload URL. Typically this is -configured in a file located at :file:`$HOME/.pypirc`. If you see a file like: - -.. code:: - - [distutils] - index-servers = - pypi - - [pypi] - repository = https://pypi.python.org/pypi - username = - password = - - -Then simply delete the line starting with ``repository`` and you will use -your upload tool's default URL. - -If for some reason you're unable to upgrade the version of your tool -to a version that defaults to using PyPI.org, then you may edit -:file:`$HOME/.pypirc` and include the ``repository:`` line, but use the -value ``https://upload.pypi.org/legacy/`` instead: - -.. code:: - - [distutils] - index-servers = - pypi - - [pypi] - repository = https://upload.pypi.org/legacy/ - username = - password = - -(``legacy`` in this URL refers to the fact that this is the new server -implementation's emulation of the legacy server implementation's upload API.) - -For more details, see the :ref:`specification ` for :file:`.pypirc`. - -Registering package names & metadata ------------------------------------- - -Explicit pre-registration of package names with the ``setup.py register`` -command prior to the first upload is no longer required, and is not -currently supported by the legacy upload API emulation on PyPI.org. - -As a result, attempting explicit registration after switching to using -PyPI.org for uploads will give the following error message:: - - Server response (410): This API is no longer supported, instead simply upload the file. - -The solution is to skip the registration step, and proceed directly to -uploading artifacts. - - -Using TestPyPI --------------- - -Legacy TestPyPI (testpypi.python.org) is no longer available; use -`test.pypi.org `_ instead. If you use TestPyPI, -you must update your :file:`$HOME/.pypirc` to handle TestPyPI's new -location, by replacing ``https://testpypi.python.org/pypi`` with -``https://test.pypi.org/legacy/``, for example: - -.. code:: - - [distutils] - index-servers= - pypi - testpypi - - [testpypi] - repository = https://test.pypi.org/legacy/ - username = - password = - -For more details, see the :ref:`specification ` for :file:`.pypirc`. - - -Registering new user accounts ------------------------------ - -In order to help mitigate spam attacks against PyPI, new user registration -through ``pypi.python.org`` was *switched off* on **February 20, 2018**. -New user registrations at ``pypi.org`` are open. - - -Browsing packages ------------------ - -While ``pypi.python.org`` is may still be used in links from other PyPA -documentation, etc, the default interface for browsing packages is -``pypi.org``. The domain pypi.python.org now redirects to pypi.org, -and may be disabled sometime in the future. - - -Downloading packages --------------------- - -``pypi.org`` is the default host for downloading packages. - -Managing published packages and releases ----------------------------------------- - -``pypi.org`` provides a fully functional interface for logged in users to -manage their published packages and releases. diff --git a/source/guides/multi-version-installs.rst b/source/guides/multi-version-installs.rst deleted file mode 100644 index 456ee22e23..0000000000 --- a/source/guides/multi-version-installs.rst +++ /dev/null @@ -1,39 +0,0 @@ -:orphan: - -.. _`Multi-version installs`: - -Multi-version installs -====================== - -:Page Status: Obsolete - - -easy_install allows simultaneous installation of different versions of the same -project into a single environment shared by multiple programs which must -``require`` the appropriate version of the project at run time (using -``pkg_resources``). - -For many use cases, virtual environments address this need without the -complication of the ``require`` directive. However, the advantage of -parallel installations within the same environment is that it works for an -environment shared by multiple applications, such as the system Python in a -Linux distribution. - -The major limitation of ``pkg_resources`` based parallel installation is -that as soon as you import ``pkg_resources`` it locks in the *default* -version of everything which is already available on sys.path. This can -cause problems, since ``setuptools`` created command line scripts -use ``pkg_resources`` to find the entry point to execute. This means that, -for example, you can't use ``require`` tests invoked through ``nose`` or a -WSGI application invoked through ``gunicorn`` if your application needs a -non-default version of anything that is available on the standard -``sys.path`` - the script wrapper for the main application will lock in the -version that is available by default, so the subsequent ``require`` call -in your own code fails with a spurious version conflict. - -This can be worked around by setting all dependencies in -``__main__.__requires__`` before importing ``pkg_resources`` for the first -time, but that approach does mean that standard command line invocations of -the affected tools can't be used - it's necessary to write a custom -wrapper script or use ``python3 -c ''`` to invoke the application's -main entry point directly. diff --git a/source/guides/single-sourcing-package-version.rst b/source/guides/single-sourcing-package-version.rst deleted file mode 100644 index 7ed3d87da3..0000000000 --- a/source/guides/single-sourcing-package-version.rst +++ /dev/null @@ -1,8 +0,0 @@ -:orphan: - -.. meta:: - :http-equiv=refresh: 0; url=../../discussions/single-source-version/ - -Redirecting stale single-source package version link... - -If the page doesn't automatically refresh, see :ref:`single-source-version`. diff --git a/source/guides/supporting-multiple-python-versions.rst b/source/guides/supporting-multiple-python-versions.rst deleted file mode 100644 index 46addbaa88..0000000000 --- a/source/guides/supporting-multiple-python-versions.rst +++ /dev/null @@ -1,135 +0,0 @@ -:orphan: - -.. _`Supporting multiple Python versions`: - -=================================== -Supporting multiple Python versions -=================================== - -:Page Status: Obsolete -:Last Reviewed: 2014-12-24 - - -:: - - FIXME - - Useful projects/resources to reference: - - - DONE six - - DONE python-future (http://python-future.org) - - tox - - DONE Travis and Shining Panda CI (Shining Panda no longer available) - - DONE Appveyor - - DONE Ned Batchelder's "What's in Which Python" - - http://nedbatchelder.com/blog/201310/whats_in_which_python_3 - - http://nedbatchelder.com/blog/201109/whats_in_which_python - - Lennart Regebro's "Porting to Python 3" - - Greg Hewgill's script to identify the minimum version of Python - required to run a particular script: - https://github.com/ghewgill/pyqver - - the Python 3 porting how to in the main docs - - cross reference to the stable ABI discussion - in the binary extensions topic (once that exists) - - mention version classifiers for distribution metadata - -In addition to the work required to create a Python package, it is often -necessary that the package must be made available on different versions of -Python. Different Python versions may contain different (or renamed) standard -library packages, and the changes between Python versions 2.x and 3.x include -changes in the language syntax. - -Performed manually, all the testing required to ensure that the package works -correctly on all the target Python versions (and OSs!) could be very -time-consuming. Fortunately, several tools are available for dealing with -this, and these will briefly be discussed here. - -Automated testing and continuous integration --------------------------------------------- - -Several hosted services for automated testing are available. These services -will typically monitor your source code repository (e.g. at -`GitHub `_ or `Bitbucket `_) -and run your project's test suite every time a new commit is made. - -These services also offer facilities to run your project's test suite on -*multiple versions of Python*, giving rapid feedback about whether the code -will work, without the developer having to perform such tests themselves. - -Wikipedia has an extensive `comparison -`_ -of many continuous-integration systems. There are two hosted services which -when used in conjunction provide automated testing across Linux, Mac and -Windows: - - - `GitHub Actions `_ provides Windows, - Linux and a macOS environments. - - `Appveyor `_ provides a Windows environment - (Windows Server 2012). - -:: - - TODO Either link to or provide example .yml files for these two - services. - - TODO How do we keep the Travis Linux and macOS versions up-to-date in this - document? - -Both `GitHub Actions`_ and Appveyor_ require a `YAML -`_-formatted file as specification for the instructions -for testing. If any tests fail, the output log for that specific configuration -can be inspected. - -For Python projects that are intended to be deployed on both Python 2 and 3 -with a single-source strategy, there are a number of options. - -Tools for single-source Python packages ----------------------------------------- - -`six `_ is a tool developed by Benjamin Peterson -for wrapping over the differences between Python 2 and Python 3. The six_ -package has enjoyed widespread use and may be regarded as a reliable way to -write a single-source Python module that can be use in both Python 2 and 3. -The six_ module can be used from as early as Python 2.5. A tool called -`modernize `_, developed by Armin -Ronacher, can be used to automatically apply the code modifications provided -by six_. - -Similar to six_, `python-future `_ is -a package that provides a compatibility layer between Python 2 and Python 3 -source code; however, unlike six_, this package aims to provide -interoperability between Python 2 and Python 3 with a language syntax that -matches one of the two Python versions: one may -use - - - a Python 2 (by syntax) module in a Python 3 project. - - a Python 3 (by syntax) module in a *Python 2* project. - -Because of the bi-directionality, python-future_ offers a pathway to -converting a Python 2 package to Python 3 syntax module-by-module. However, in -contrast to six_, python-future_ is supported only from Python 2.6. Similar to -modernize_ for six_, python-future_ comes with two scripts called ``futurize`` -and ``pasteurize`` that can be applied to either a Python 2 module or a Python -3 module respectively. - -Use of six_ or python-future_ adds an additional runtime dependency to your -package: with python-future_, the ``futurize`` script can be called with the -``--stage1`` option to apply only the changes that Python 2.6+ already -provides for forward-compatibility to Python 3. Any remaining compatibility -problems would require manual changes. - -What's in which Python? ------------------------ - -Ned Batchelder provides a list of changes in each Python release for -`Python 2 `__, -`Python 3.0-3.3 `__ and -`Python 3.4-3.6 `__. -These lists may be used to check whether any changes between Python versions -may affect your package. - -:: - - TODO These lists should be reproduced here (with permission). - - TODO The py3 list should be updated to include 3.4 diff --git a/source/guides/supporting-windows-using-appveyor.rst b/source/guides/supporting-windows-using-appveyor.rst deleted file mode 100644 index b661024f70..0000000000 --- a/source/guides/supporting-windows-using-appveyor.rst +++ /dev/null @@ -1,235 +0,0 @@ -:orphan: - -================================= -Supporting Windows using Appveyor -================================= - -:Page Status: Obsolete -:Last Reviewed: 2015-12-03 - -This section covers how to use the free `Appveyor`_ continuous integration -service to provide Windows support for your project. This includes testing -the code on Windows, and building Windows-targeted binaries for projects -that use C extensions. - - -Background -========== - -Many projects are developed on Unix by default, and providing Windows support -can be a challenge, because setting up a suitable Windows test environment is -non-trivial, and may require buying software licenses. - -Windows users typically do not have access to a C compiler, and therefore are -reliant on projects that use C extensions distributing binary wheels on PyPI in -order for the distribution to be installable via ``python -m pip install ``. By -using Appveyor as a build service (even if not using it for testing) it is -possible for projects without a dedicated Windows environment to provide -Windows-targeted binaries. - -Setting up -========== - -In order to use Appveyor to build Windows wheels for your project, you must -have an account on the service. Instructions on setting up an account are given -in `the Appveyor documentation `__. The free tier -of account is perfectly adequate for open source projects. - -Appveyor provides integration with `GitHub`_ and `Bitbucket`_, so as long as -your project is hosted on one of those two services, setting up Appveyor -integration is straightforward. - -Once you have set up your Appveyor account and added your project, Appveyor will -automatically build your project each time a commit occurs. - -Adding Appveyor support to your project -======================================= - -In order to define how Appveyor should build your project, you need to add an -:file:`appveyor.yml` file to your project. The full details of what can be -included in the file are covered in the Appveyor documentation. This guide will -provide the details necessary to set up wheel builds. - -Appveyor includes by default all of the compiler toolchains needed to build -extensions for Python. For Python 2.7, 3.5+ and 32-bit versions of 3.3 and 3.4, -the tools work out of the box. But for 64-bit versions of Python 3.3 and 3.4, -there is a small amount of additional configuration needed to let distutils -know where to find the 64-bit compilers. (From 3.5 onwards, the version of -Visual Studio used includes 64-bit compilers with no additional setup). - -appveyor.yml ------------- - -.. literalinclude:: appveyor-sample/appveyor.yml - :language: yaml - :linenos: - -This file can be downloaded from `here `__. - -The :file:`appveyor.yml` file must be located in the root directory of your -project. It is in ``YAML`` format, and consists of a number of sections. - -The ``environment`` section is the key to defining the Python versions for -which your wheels will be created. Appveyor comes with Python 2.6, 2.7, 3.3, -3.4 and 3.5 installed, in both 32-bit and 64-bit builds. The example file -builds for all of these environments except Python 2.6. Installing for Python -2.6 is more complex, as it does not come with pip included. We don't support -2.6 in this document (as Windows users still using Python 2 are generally able -to move to Python 2.7 without too much difficulty). - -The ``install`` section uses pip to install any additional software that the -project may require. The only requirement for building wheels is the ``wheel`` -project, but projects may wish to customise this code in certain circumstances -(for example, to install additional build packages such as ``Cython``, or test -tools such as ``tox``). - -The ``build`` section simply switches off builds - there is no build step needed -for Python, unlike languages like ``C#``. - -The main sections that will need to be tailored to your project are ``test_script`` -and ``after_test``. - -The ``test_script`` section is where you will run your project's tests. The -supplied file runs your test suite using ``setup.py test``. If you are only -interested in building wheels, and not in running your tests on Windows, you -can replace this section with a dummy command such as ``echo Skipped Tests``. -You may wish to use another test tool, such as ``nose`` or :file:`py.test`. Or -you may wish to use a test driver like ``tox`` - however if you are using -``tox`` there are some additional configuration changes you will need to -consider, which are described below. - -The ``after_test`` runs once your tests have completed, and so is where the -wheels should be built. Assuming your project uses the recommended tools -(specifically, ``setuptools``) then the ``setup.py bdist_wheel`` command -will build your wheels. - -Note that wheels will only be built if your tests succeed. If you expect your -tests to fail on Windows, you can skip them as described above. - - -Support script --------------- - -The :file:`appveyor.yml` file relies on a single support script, which sets up -the environment to use the SDK compiler for 64-bit builds on Python 3.3 and -3.4. For projects which do not need a compiler, or which don't support 3.3 or -3.4 on 64-bit Windows, only the :file:`appveyor.yml` file is needed. - -`build.cmd `__ -is a Windows batch script that runs a single command in an environment with the -appropriate compiler for the selected Python version. All you need to do is to -set the single environment variable ``DISTUTILS_USE_SDK`` to a value of ``1`` -and the script does the rest. It sets up the SDK needed for 64-bit builds of -Python 3.3 or 3.4, so don't set the environment variable for any other builds. - -You can simply download the batch file and include it in your project unchanged. - - -Access to the built wheels --------------------------- - -When your build completes, the built wheels will be available from the Appveyor -control panel for your project. They can be found by going to the build status -page for each build in turn. At the top of the build output there is a series -of links, one of which is "Artifacts". That page will include a list of links -to the wheels for that Python version / architecture. You can download those -wheels and upload them to PyPI as part of your release process. - -Additional notes -================ - -Testing with tox ----------------- - -Many projects use the :doc:`Tox ` tool to run their tests. It ensures that tests -are run in an isolated environment using the exact files that will be distributed -by the project. - -In order to use ``tox`` on Appveyor there are a couple of additional considerations -(in actual fact, these issues are not specific to Appveyor, and may well affect -other CI systems). - -1. By default, ``tox`` only passes a chosen subset of environment variables to the - test processes. Because ``distutils`` uses environment variables to control the - compiler, this "test isolation" feature will cause the tests to use the wrong - compiler by default. - - To force ``tox`` to pass the necessary environment variables to the subprocess, - you need to set the ``tox`` configuration option ``passenv`` to list the additional - environment variables to be passed to the subprocess. For the SDK compilers, you - need - - - ``DISTUTILS_USE_SDK`` - - ``MSSdk`` - - ``INCLUDE`` - - ``LIB`` - - The ``passenv`` option can be set in your :file:`tox.ini`, or if you prefer - to avoid adding Windows-specific settings to your general project files, it - can be set by setting the ``TOX_TESTENV_PASSENV`` environment variable. The - supplied :file:`build.cmd` script does this by default whenever - ``DISTUTILS_USE_SDK`` is set. - -2. When used interactively, ``tox`` allows you to run your tests against multiple - environments (often, this means multiple Python versions). This feature is not as - useful in a CI environment like Appveyor, where all tests are run in - isolated environments for each configuration. As a result, projects often supply - an argument ``-e ENVNAME`` to ``tox`` to specify which environment to use (there - are default environments for most versions of Python). - - However, this does *not* work well with a Windows CI system like Appveyor, where - there are (for example) two installations of Python 3.4 (32-bit and 64-bit) - available, but only one ``py34`` environment in ``tox``. - - In order to run tests using ``tox``, therefore, projects should probably use the - default ``py`` environment in ``tox``, which uses the Python interpreter that - was used to run ``tox``. This will ensure that when Appveyor runs the tests, they - will be run with the configured interpreter. - - In order to support running under the ``py`` environment, it is possible that - projects with complex ``tox`` configurations might need to modify their - :file:`tox.ini` file. Doing so is, however, outside the scope of this - document. - -Automatically uploading wheels ------------------------------- - -It is possible to request Appveyor to automatically upload wheels. There is a -``deployment`` step available in :file:`appveyor.yml` that can be used to (for -example) copy the built artifacts to a FTP site, or an Amazon S3 instance. -Documentation on how to do this is included in the Appveyor guides. - -Alternatively, it would be possible to add a ``twine upload`` step to the -build. The supplied :file:`appveyor.yml` does not do this, as it is not clear -that uploading new wheels after every commit is desirable (although some -projects may wish to do this). - -External dependencies ---------------------- - -The supplied scripts will successfully build any distribution that does not -rely on 3rd party external libraries for the build. - -It is possible to add steps to the :file:`appveyor.yml` configuration -(typically in the "install" section) to download and/or build external -libraries needed by the distribution. And if needed, it is possible to add -extra configuration for the build to supply the location of these libraries to -the compiler. However, this level of configuration is beyond the scope of this -document. - - -Support scripts ---------------- - -For reference, the SDK setup support script is listed here: - -``appveyor-sample/build.cmd`` - -.. literalinclude:: appveyor-sample/build.cmd - :language: bat - :linenos: - -.. _Appveyor: https://www.appveyor.com/ -.. _GitHub: https://github.com -.. _GitHub Actions: https://docs.github.com/en/actions -.. _Bitbucket: https://bitbucket.org/ diff --git a/source/guides/using-manifest-in.rst b/source/guides/using-manifest-in.rst deleted file mode 100644 index 24bf154a12..0000000000 --- a/source/guides/using-manifest-in.rst +++ /dev/null @@ -1,9 +0,0 @@ -:orphan: - -============================================================ -Including files in source distributions with ``MANIFEST.in`` -============================================================ - -The information on this page has moved to -:doc:`setuptools:userguide/miscellaneous` in the setuptools -documentation. diff --git a/source/tutorials/creating-documentation.rst b/source/tutorials/creating-documentation.rst deleted file mode 100644 index 5d9dae7871..0000000000 --- a/source/tutorials/creating-documentation.rst +++ /dev/null @@ -1,7 +0,0 @@ -:orphan: - -Creating documentation -====================== - -This tutorial has been removed since it is not related to packaging and was unmaintained. -Please see the `Sphinx tutorial `_ instead.